Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-25 19:31:51

On Mar 25, 2007, at 5:53 PM, Emil Dotchevski wrote:

> If this is correct, and if N2178 is accepted, then zero-overhead try/
> timed join becomes available across the the board. If N2184 is
> accepted, then zero-overhead try/timed join becomes unavailable
> across the board, regardless of whether it is possible from a
> technical point of view.

I've been hesitant to say this, but it may be possible to add try/
timed_join to N2184. I know that it definitely could be added to my
pthreads-based implementation of N2184 (well, I haven't actually done
it so maybe definitely is too strong - 98% sure). And by added here,
I mean at no extra cost.

What has me worried about adding try/timed_join to N2184 is actually
N2178! :-)

I implemented N2184 for one of the "problem platforms" that I
mentioned in my post concerning C/C++ cancellation interoperability:
Mac OS X. I can not currently implement a pthread_cancel on this
platform that will work in C++. This is both good and bad. The bad
is obvious: no C/C++ interoperability.

The good is that it forced me to not implement std::thread::join in
terms of pthread_join. Because thread::join must be a C++
cancellation point, and pthread_join isn't a C++ cancellation point
(if you can't use pthread_cancel), then one must implement
thread::join in terms of a mutex/cv stored in thread local data (and
thread local data is hopefully coming via N2147). The reason for this
is that condition is the only trigger I have in the tool box to wake a
sleeping thread so it can be canceled.

That makes it zero cost to add siblings of thread::join which do
try_join (just check the done flag in thread local data), and
timed_join (use cv/timed_wait).

However if thread::cancel is implemented in terms of pthread_cancel,
that means that there is pressure to implement thread::join in terms
of pthread_join (because cancellation then works). And there is no
pthread_try_join or pthread_timed_join so if these were required at
the C++ level, then you've added a feature that adds cost.

The other, extremely remote, possibility is to ask the posix group to
add pthread_try_join and pthread_timed_join. They might even be
willing to do this. However there is just no way we're going to get
that committee to mandate that pthread_cancel emits a catchable C++
exception. And in that case pthread_try_join and pthread_timed_join
are useless to us anyway.

Thread cancellation is at the heart of a lot of these issues! :-\


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