Re: MT Design Question
"Scott Meyers" <NeverRead@aristeia.com>
I failed to explain that there are two kinds of failure:
- Normal: Search was completed, no suitable node was found.
- Exceptional: Search was aborted with an exception of some kind.
I agree that in the case of a normal failure, the other threads can be
interrupted at that point. If a failure is exceptional, the other threads
probably need to be allowed to continue.
Clear now :)
If all runners have their separate location to store the result, I'd
start with a single atomic<bool> that is the finish sign. Each thread
polls it regularly and if finds set, cancels its work, exiting. And
whoever finishes naturally sets it.
Okay, so you'd poll, which was one of the strategies I mentioned.
No, the poll you suggested is a different kind of animal. What said here is
internal in the promise and is done before proceeding with useful fork -- to
provide early exit. IOW that is the cooperative way of thread canceling. I
doubt you can avoid it if you actually aim to waste processor cycles after
the goal is reached.
Where you do suggest poll as strategy is replaced by using join. There are
no excess wakeups and busy or semi-busy waits.
Having no locks at all it seem efficient for a single-core environment.
On multicore there will be a ton of reads around a shared byte, but
unless atomic<> has some weird penalty it shall not be a problem either,
at least I don't see how other sync stuff would be better.
Do you have a reason for preferring polling to use of a condition variable
or, as others have suggested, a semaphore?
Sure. :) The main reason is none of that is actually needed in the schema.
The thread ITSELF is a sync primitive, and works much like a cond/event. If
you can use it, there is no point to create one extra manually.
I'd use those if the threads do not stop immediately but linger on to do
some other job. Like when a thread pool is used.
Reading other parts of this topic it seem std::future is not serving too
well for your setup. So if you want performance possibly you better go with
just launching threads. Besides the problem of lacking
WaitForMultipleObjects-equivalent, I don't see a straightforward way to
avoid creating an extra thread. (As I put out, the main thread can run one
search so only 2 others are created; in setups where you have the same
amount of cores as parallel paths it is quite important to not have
parazites...)
Still there may be a way to chain the promises. i imagine a lisp-like
solution, having a list processor that calculates the result for (car)
itself returning a joint result fith thar of (cdr). IOW your promise also
has a future it executes. On the top you wait for the first that will
complete waiting on the second that on the third... And passing in the
extra atomic<bool> for the early-termination signal shall not be a hard
addition. May worth exploring.