Boost logo

Boost :

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?
>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

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.

>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

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