Re: MT Design Question
"Scott Meyers" <NeverRead@aristeia.com>
Balog Pal wrote:
Say, start with 0, and every thread completed does an increment. For your
situation as soon as it is at 3 work is done. certainly that leaves you
with your original problem in the main thread what to do until all bumps
happened.
Doing a poll from this, really IDLE thread is really not good. You
already fiddled with cond+fake mutex, that is a working way. I could
suggest an alternative: use just a mutex.
1. main thread sets variable atomic<int> to N that is the number of
threads (N=3 in your example.
2. create and lock a mutex
3. launch N threads. on exit each decrements the variable, if the result
is zero unlocks the mutex. (They use the cancel signal to each other too
certainly.)
4. main thread waits on the mutex.
Interesting idea, thanks. I'd been thinking that each worker would notify
the main thread when it was done. At each notification, the main thread
would check the result to see if it was "real" or an exception, and if
real, it would tell the remaining workers to stop working.
The lighter way is to not look at the counter value in the thread send
notify blindly and inspect in main. That removes a little knowledge-export
but creates extra wakeups.
What you write is to check the whole 'done this far' state, effectively
re-evaluating it. Means re-inspect all your threads' result area, probably
mark some, etc -- smells as a ton of redundant processing. Needed only
because you changed the place from where the native information is present
to where it is lost. Overall complexity grows.
In his book, Anthony Williams uses TLS for each worker's "stop now" flag,
and, within each worker, checking that flag would presumably be faster
than accessing a shared flag such as you suggest.
Hm, I seriously doubt Anthony would suggest that -- I'd think the
comparision probably used some other method (like a mutex-protected
variable). I also fail to see a simple way to change the flag state from
another thread if it is in TLS... Please give me some reference, then if
still in doubt we can ask him (normally he's active on ACCU...)
If you use a mutex then contension is really a thing to consider, as
everyone will keep flipping it. With possible collisions too, so separation
may due.
If you use atomic instead the picture is different. Mostly because it keeps
the state, and changes only once. You have a zillion reads, but those do
not block, only make sure the cache is not invalidated. So I don;t see
how separation would make anything better contention-wise.
Certainly it would be more encapsulated; having multiple threads share
the "stop now" flag makes me think of global variables, which is something
I really don't like to think about.
Global? The solutions I presented had all the state in the stack frame where
you start the search. Can't imagine anything more local ;-) You only pass
addresses around.
And sharing them naturally maps your requirement: IIRC to stop *all*
siblings as soon as any one found the solution. So they best to have that
signal shared for all. Reasons may surface to organize differently, but I
see it as deviation, or de-normalization.
Your approach also makes it tougher to detect that e.g., some workers
threw an exception while others ran to completion.
I fail to see how that is harder or easier -- once done the main thread scan
the results and evaluate them. Same algo. (We did NOT share the 'final
result' area for reasons discussed earlier, that would make it a simple
read, hope you did not compare against that.)
But I see how it works, thanks again for the idea.
For the encapsulation/logic distribuition, I think you miss a detail. I
wrote the logic in 'abstract'. In real life, it is often packaged
differently, what as a side effect covers your concerns.
Like instead of passing in the atomic<int> counter and the mutex, I'd pass
in a functor, that the thread shall call on finish. (in a general framework
I'd probably have 2 functors, to call before and after payload work..)
The functor -- a simple instance of boost::bind or sigc::bind -- holds the
logic to decrement and unlock. Or do whatever else you want delegated to
help the main thread. You may even include the logic to inspect the result
and set the shared stop flag. Or join the neighbor, etc.
Or an alternative implementation would have a base class doing the control
logic, and have your "search" implementation as virtual or strategy.