RE: boost::thread::join semantics

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-30 11:09:17

From: "Peter Dimov" <pdimov_at_[hidden]>
From: "William Kempf" <williamkempf_at_[hidden]>
>Why the stricter requirement of undefined behavior for subsequent joins? 
>Why
>not simply 'no effect'?

From a very low level point of view it's for the same reason that calling 
"delete" on the same pointer multiple times results in undefined behavior.  
From a higher level design point of view it's because there's no added 
benefit to "no effect" semantics, unless it were made valid to call join 
from default constructed thread objects as well... which brings us back to 
the issue of adoption.  The stricter requirements make adoption easy to 
implement on both platforms.

>Is boost::thread thread safe? IOW are calls to boost::thread::join
>serialized?

Since it's a programmatic error (undefined behavior) to call join() multiple 
times there's no need for serialization or concerns over thread safety.

>What happens when two threads simultaneously call x.join()?

Undefined behavior, regardless of any issues of serialization.

>[Analysis:
>
>case 1: access not serialized. Undefined behavior.

True, but an implementation detail.

>case 2: access serialized. Undefined behavior (second join.)

True by design.

>case 3: access serialized, subsequent joimns have no effect. Well defined
>behavior. Both threads join x.]

Actually, only one thread "joins x", by very definition of "join" ;).  That 
aside, this is an alternative design, but one that complicates thread 
adoption, and so was not the design I went with.  Beyond the issue of thread 
adoption, this alternate design also adds overhead (possibly significant 
overhead), so the principle of only paying for what you use also applies.

Bill Kempf

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp