Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-27 09:20:16

On Mar 27, 2007, at 4:21 AM, Anthony Williams wrote:

> Wow. I leave things for a few days and there's loads of messages to
> deal with.

Alright, Anthony's back. Everybody behave! :-)

> t.detach() t.join() harmless race. Either thread is detached
> first, so
> join is no-op, or thread is joined first,
> so
> detach is no-op.

This one has me worried as it seems like such a race is likely to be a
logical error in the program.

Consider the following example:

t's job is to compute some data so that Thread A can take the data and
do whatever with it. So Thread A joins with t. Upon successful join
Thread A should be able to assume that t successfully completed the
computation, or ran into some kind of non-recoverable error:

t Thread A
compute data ...
                         if invalid data
                             report unrecoverable error
                             process data

But now add Thread B into this mix which calls t.detach():

t Thread A Thread B
                         if invalid data
                             report unrecoverable error
                             process data
compute data

Now it is possible for Thread A to return from the join() while t is
still busy computing the data. The data is neither invalid nor
valid. It just isn't there yet. This was supposed to be exactly the
problem join() solves. Now Thread A needs to deal with "spurious
joins" much like with condition::wait:

                          while (data not ready)

Oops, that doesn't work either. The second join() is a no-op as
well. I just accidently wrote a polling loop on while(data not ready).

                          while (data not ready)

This is a departure from pthread semantics that I am uncomfortable
with. If I accidently get myself into this kind of race. I think I'd
prefer some noise (an assert, or exception, or crash).


Boost list run by bdawes at, gregod at, cpdaniel at, john at