Re: MT Design Question
On Aug 25, 7:57 pm, Scott Meyers <NeverR...@aristeia.com> wrote:
James Kanze wrote:
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.
This isn't quite true. The calling thread can read the future
as soon as it's set by the callee (via the corresponding
promise). The callee thread may then run for a while longer,
e.g., to invoke destructors of local objects and thread-local
objects. If the thread runs detached, there may never be
a join, although that complicates matters at program shutdown.
In other words, it uses a condition in its implementation. (I'm
not sure how this works with exceptions, though.)
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.
This sounds like your design had the master thread wait until
all worker threads were done, i.e., until the table was
completely filled in. Is that correct?
In my case, yes. In practice, the master thread was woken up
each time a worker thread updated the table. It then checked
whether it had all the information it needed, and went back to
sleep if not.
My problem is more along the lines of wanting to wake the
master when any entry in the table is filled in with
a non-exception result. But that just pushes the notification
problem into the table object: how is it to know when
a thread has posted a non-exception result if it doesn't use
When the worker thread updates the table, it locks the mutex,
makes the modifications, then called pthread_cond_signal on the
condition and freed the mutex. The master thread then woke up,
and checked the conditions.