Re: [boost] RE: boost::thread::join semantics

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-30 11:41:31

From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_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.

You need to remember whether 'join' was called anyway (for the destructor.)
So you can easily avoid the 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.

No, let's leave adopted threads aside for now. Let us focus on joinable
thread objects that are joined twice. I'm fine with the undefined behavior
on joining an adopted thread.

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

This is a general question, it's not limited to 'join.' In the future there
will be many things that you can do to a thread object - cancel,
set_cancel_type, set_priority, etc. Are these operations thread-safe?

> >case 3: access serialized, subsequent joins have no effect. Well defined
> >behavior. Both threads join x.]
>
> Actually, only one thread "joins x", by very definition of "join" ;).

The definition of join is:

Effects: The current thread of execution blocks until the initial function
of the thread of execution represented by *this finishes and all resources
are reclaimed.

Postcondition: *this is non-joinable.

Both threads join x, by this definition. You can't detect from a conforming
program how many threads joined x simultaneously. (Ignoring the non-joinable
vs adopted-non-joinable issue for now.)

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

I don't see why this complicates thread adoption; it's a separate issue.
Joining an adopted thread will invoke undefined behavior, as usual.

As for the overhead... what overhead? Join blocks for an indeterminate
amount of time anyway; and the second join is undefined behavior by the
current specification so there's no added overhead here either.

--
Peter Dimov
Multi Media Ltd.