Re: MT Design Question
On Aug 25, 12:24 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
Scott Meyers <NeverR...@aristeia.com> wrote
innews:i51fus$hft$1@news.albasani.net:
Paavo Helde wrote:
But there is a shared state, namely the results. When the
worker thread has found some result, it has to write it
somewhere where the main thread can find it.
This is what a future is for. As I noted, my plan is for
each search function to have its own future. In C++0x,
callees write their result to a promise, and callers
retrieve the result through a future. The state shared by
a promise and future is internally synchronized, so there is
no need for clients to use a mutex with it.
I see. I overlooked the usage of C++0x future<> in the OP.
I am not familiar with this feature, but it appears to be
a higher level construct having internal synchronisation.
Yes. The intent, if I understand it correctly, is to
encapsulate the creation of the thread and its join. The
results data are set in the thread, and only read after the join
in the creating thread.
And again, IIUC, Scott's problem can be summarized as "you can
only wait for one future at a time". You can poll them, in
a loop, but Scott, very understandably, doesn't want to do that.
I'm not as familiar as I'd like to be with the proposed
threading in the standard, but I have handled a similar problem
with Posix threads: I made the threads detached (so no join was
available), and used a (single) condition to communicate, with
a table of results, one per thread.
--
James Kanze