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