Share thread among objects

[Kejpa]

Hi,
I'm logging the values my app is producing, in order to keep the logs small
I zip them hourly.
My problem lies in that two (or more) different objects discover that the
hour has changed and each tries to start a thread to create the hourly zip.
The runner up discovers that there is no file and creates it, but during
this time the first thread already has created the file and I get an "File
already exists"-error.

Basically, I want the object that first discovers a change of hour to start
a single thread where the zip occurs. The runner up object should notice
that the thread is started/zip exists and just add the previous log file to
the zip.

TIA
Kejpa

 

[Cor Ligthert]

Kepja,

My simple answer is catch that error and close the thread.

What am I missing with this answer?

Cor

 

[Kejpa]

Kepja,

My simple answer is catch that error and close the thread.

What am I missing with this answer?

Probably nothing. I was just not sure wheather or not that was the
best/cleanest way to do it...

/Kejpa

 

[Jay B. Harlow [MVP - Outlook]]

Kejpa,
Is each object running in their own thread?

I would consider separating the logic that creates the zip file from the
objects themselves. Let the objects themselves simply write to the log file.

I would then use either the System.Timers.Timer.Elapsed event or a
System.Threading.Timer callback to start the zip method.


Alternatively you can use one or more SyncLock statements to ensure that
only a single Thread is zipping the file at a time. Primarily you want a
SyncLock around the time check to see if zipping needs to occur. I would
consider putting a separate SyncLock (on a different lock object) around the
zipping itself, just to be certain.

Hope this helps
Jay

 

[Cor Ligthert]

Kepja,

I have assumed from your messages that the information in both Zip files is
absolute the same and that it is exactly the same kind of process that
starts in almost the same time.

Before we understand each other wrong.

Cor

 

[Kejpa]

Yes,
there will be one zip-file per hour.
The objects all write to the same log file and when a new hour has begun the
log-file should be added to the zip archive.

/Kejpa

 

[Kejpa]

Is each object running in their own thread?
Yup, each object is listening for messages and write down them to the log as
they arrive.

I would consider separating the logic that creates the zip file from the
objects themselves. Let the objects themselves simply write to the log

file.
You mean I should create just one global log object and let the listeners
use that one?
Currently I'm creating a separate log object for each object, when the log
object discovers a change of hour it starts a separate thread that will zip
the log.

Alternatively you can use one or more SyncLock statements to ensure that
only a single Thread is zipping the file at a time. Primarily you want a
SyncLock around the time check to see if zipping needs to occur. I would
consider putting a separate SyncLock (on a different lock object) around the
zipping itself, just to be certain.

I am using synclock on the zip file (IO.FileInfo object) but it still messes
up now and then.

Hope this helps
Jay

Sure does,
At least I'm not sure I did the right thinking at first

Regards
/Kejpa

 

[Jay B. Harlow [MVP - Outlook]]

Kejpa,
It sounds like each log object writes to a single log file, correct?

Each thread can have its own log object, although I normally have a single
log object (as its easier to share the padlock itself (the object that is
SyncLocked)). Either way: I am suggesting the log object does not do the
zipping.

I am suggesting creating a single zip object that based on a timer
(System.Timers.Timer or
System.Threading.Timer) adds the single log file to the zip file. The reason
I am suggesting this is that I expect the act of zipping takes longer then
the act of writing a log entry. The zip thread could rename the log & create
a new log allowing the other threads to keep running, then the zip thread
could save the log file to the zip file at its leisure.

I am using synclock on the zip file (IO.FileInfo object) but it still
messes
up now and then.

When you use SyncLock you need to be certain that the object that is being
locked is shared between all threads. Also you need to be certain you are
locking enough code without locking too much.

It might be helpful if you could show us your log & zipping code, that way I
or someone else may be able to see why the zipping doesn't work as you
expect.

Hope this helps
Jay