Re: [boost] [thread] thread interruption semantics

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-15 07:37:25

Hi Howard,

Howard Hinnant wrote:
> If pthread semantics can be implemented more efficiently using atomics  
> (which C++0X will have), then that's great.  There is no requirement  
> that pthread_cond_t be at the center of std::condition_variable.

Thanks for the clarification.  You might like to adjust the 
documentation to say that the implementation is expected to be no 
slower than any native mutex / condition variable.

> On the other hand, this is an OS-level functionality.  If the semantics  
> of pthread_cond_t can be implemented more efficiently on some platform  
> than is currently done, I imagine that the OS vendor will likely do  
> it, and call it pthread_cond_t.

The semantics of pthread_mutex&cond_t are more complex than are needed 
for std::mutex&cond_var.  Slightly more efficient pthread functions 
could be implemented by inlining (maybe some implementations already do 
this).  But the overhead of using a single type for all kinds of mutex 
(recursive, non-recursive, checking etc), with run-time look up of the 
kind, is unavoidable.  Since the optimal uncontended mutex locking code 
is just two inline instructions, even adding one additional 'if 
kind==x' will measurably reduce performance.

>> 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().
>
> The Posix committee has considerable experience and expertise in this  
> area.  While I do not trust their advice blindly, I also do not  
> dismiss it lightly (quite the contrary).  Transferring mutex ownership  
> among threads is not one of the decisions they have made that I've  
> questioned.  I've lacked the motivation.  If you have strong  
> motivation for relaxing this restriction, coupled with some insight  
> into the posix decision and why it should be relaxed, I am most  
> interested.

You are not the only one to have argued in this thread that the 
status-quo has been arrived at as a result of much deliberation by 
experts whose conclusions we should trust.  While I don't exactly 
disagree with that attitude, I suggest that the level of deference 
might perhaps be dropped back one notch.

The rationale section in the pthread_mutex documentation says nothing 
about the restriction on locking in one thread and unlocking in 
another.  Maybe some readers can propose an explanation?  My guess is 
that someone, long ago, decided to prohibit behaviour that they 
couldn't think of a use for, and that this has simply been carried forward.

My motivation for relaxation is simply that it's useful (essential?) in 
the algorithm that I presented for a condition variable.  (I'm curious 
to know if anyone has spotted any fundamental problems with that 
algorithm, by the way.)

Regards,  Phil.