Re: [boost] Boost.Threads, N2178, N2184, et al

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             ...
                         t.join();
                         if invalid data
                             report unrecoverable error
                         else
                             process data

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

t                      Thread A                                Thread B
                          ...                                    
t.detach()
                         t.join();
                         if invalid data
                             report unrecoverable error
                         else
                             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)
                              t.join();

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).

-Howard