Re: [boost] Boost.Threads, N2178, N2184, et al

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! :-\

-Howard