Re: 2 different threads checking on same variable scenario
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Wed, 09 May 2007 10:26:16 -0700
On Wed, 09 May 2007 08:58:29 -0700, David <nospam@xxxxxxxxxx> wrote:
interesting... I'll check out that overload. Do you see this as just
'another' way to accomplish this or are there certain pros/cons that may
make one a better choice than the other
To me, it depends on what you intend to do in your main thread's loop.
Because you are implementing a console application here, it seems to me that a third way to implement this would be to simply have the main thread call some "do work" function repeatedly. That function would make as much progress toward the goal as you want for each "update" (where an "update" may just be writing a new "." to the console output), would return to the caller so it can handle the "update" and when called again would resume where it left off.
This would be especially appropriate if the work you need to do is already conveniently broken into multiple chunks (for example, it involves a loop that processes a list of files), where the the top-level loop in your main thread can handle managing the list of chunks to process (that way the "do work" function doesn't even need to maintain any state between calls...the caller is handling that for it).
Depending on just what you intended to do in your "do progress indicator thing" loop, there may be a fourth option. That is, use an auto-reset wait event to block the main thread between progress updates, a flag to indicate when the work has been done, and then have the worker thread set the flag when it's done, and intermittently set the wait event to indicate to the main thread to update the progress.
To summarize, here's four different ways I see as having been mentioned in this thread:
#1:
volatile bool fDone = false;
// start worker thread
while (!fDone)
{
Sleep(...);
// update progress
}
In the worker thread, fDone is set when the work has been completed.
#2:
AutoResetEvent event = new AutoResetEvent(false);
// start worker thread
while (!event.WaitOne(new TimeSpan(0, 0, 1), false))
{
// update progress
}
In the worker thread, the event is set when the work has been completed.
#3:
AutoResetEvent event = new AutoResetEvent(false);
volatile bool fDone = false;
// start worker thread
while (!fDone)
{
event.WaitOne();
// update progress
}
In the worker thread, the event is set when the main thread should update the progress indication, and the fDone flag is set when the work is done..
#4:
foreach (WorkItem item in WorkCollection)
{
item.DoWork();
// update progress
}
There's no worker thread. The main thread just iteratively performs work, updating progress between calls to the method that does work. You may or may not have exactly the above data structure design. For example, instead of having a class that encapsulates the work items, you might just have some list of objects (strings containing filenames, for example), and a method in some other class (your main Program class, for example) that does some work on a single object (takes a filename and does some processing on that file, for example).
To compare and contrast the various methods:
The first two provide progress updates on a strictly time-based interval. The upside is that you always have some feedback to the user. The downside is that feedback doesn't really indicate what progress has been made; in fact, the worker thread could completely lock up and you'd still show progress as being made.
Between the first two, I don't see too much difference. They both use slightly different mechanisms to accomplish very much the same thing.
The second two provide progress updates that are tied to the actual work being done. The upside is that you have direct indication of the progress being made. The downside is that the feedback may or may not be provided in a timely manner. Both of the second pair do rely on the work being done having regular "checkpoints" at which it makes sense to update the progress.
Between the second pair, probably the biggest difference is that with option #4, you don't even have to make a new thread. It does rely on the main thread having more involvement with the work being done, however. If you want greater encapsulation, option #3 is probably more desirable.
This is not even a complete analysis. As you can see, there's a wide variety of approaches to doing what you want. They are roughly equivalent in that they all get the job done, but they all have different specific behaviors, and different demands on the architecture of the part of your code that actually does work.
I hope I have helped, rather than further confusing the issue. I realize sometimes all someone wants is to be told "do it this way"...I even find myself in that position sometimes. :)
Pete
.
- Follow-Ups:
- References:
- 2 different threads checking on same variable scenario
- From: David
- Re: 2 different threads checking on same variable scenario
- From: Willy Denoyette [MVP]
- Re: 2 different threads checking on same variable scenario
- From: David
- 2 different threads checking on same variable scenario
- Prev by Date: Re: IStream.Read()
- Next by Date: Re: How to use generics?
- Previous by thread: Re: 2 different threads checking on same variable scenario
- Next by thread: Re: 2 different threads checking on same variable scenario
- Index(es):
Relevant Pages
|
