Re: [boost] [thread] thread interruption semantics

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-14 17:14:29

Howard Hinnant wrote:
>Andrey Semashev wrote:
>> Beman Dawes wrote:
>>>
>>> I'm not totally enthralled by the condition_variable_any name. If
>>> someone has a suggestion for a more meaningful name, now is a good  
>>> time to speak up.

cond_var would better for my carpal tunnels....  I was also happy with 'condition'.
(Very long names should perhap be reserved for bad things.  The time 
that it takes me to type reinterpret_cast is normally long enough to 
make me reconsider whether it's appropriate!)

>> I wonder why not making condition_variable a template with a mutex  
>> type in its template parameter. We could specialize it on the boost::mutex
>> type to have the current optimized condition_variable implementation  
>> and leave it implemented as condition_variable_any for a general case.
>
> The rationale for the current design (with different names) can be  
> found here:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#condition_rationale

Thanks for the link.  Quote:

     "For those platforms which offer a native condition variable (e.g. pthread_cond_t),
      C++ should offer as thin a wrapper as possible around that OS functionality."

I think this is a mistake.  What is the motivation?  Portability, perhaps?

By wrapping the existing functionality, we bound the performance that 
we can achieve: we'll never be faster than C code.  High-performance 
concurrency primitives will be crucial to getting the most from the 
next generations of multi-core hardware.  We should at least be 
considering building from the most basic building blocks available.  
(Consider the shared_ptr implementation, for example, which only falls 
back to pthread_mutex if it doesn't have a better solution using atomics.)

My experience with pthread_mutex is that it's simple to write 
significantly faster (but less-portable) mutexes, and I think that 
Boost should be taking that approach, with the wrapped OS functionality 
offered only as a fallback.

I have not yet tried to benchmark pthread_cond, but I would be 
surprised to find it faster than the condition variable using mutexes 
that I posted elsewhere in this thread [though that code may well have 
some horrible flaw in it.....].

Apart from performance, another problem with wrapping existing 
functionality is that the lowest common denominator of all the 
constraints from the existing implementations has to be passed on to 
the user.  For example, in the condition variable code that I posted, a 
mutex is locked from one thread and then unlocked from another.  I 
think this works for all of the mutexes that I've written (spinlock, 
loop-calling-yield, futex) (though I may be missing something - I'm not 
an expert in any of this).  Because it works with futex, I guess that 
the Linux pthread_mutex may also work in DEFAULT mode, though it's 
possible that there is something in glibc that breaks it.  However, 
POSIX says that "if a thread attempts to unlock a mutex that it has not 
locked ... undefined behavior results."  So the wording in N2447 also 
requires that "the current thread of execution shall own the mutex" 
before it can call unlock().

Regards,  Phil.