Re: [boost] [thread] thread interruption semantics

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-15 16:51:05

Howard Hinnant wrote:
> On Nov 15, 2007, at 7:37 AM, Phil Endecott wrote:
>
>> 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.
>
> Your argument above addresses pthread_mutex_t but not pthread_cond_t.

pthread_cond_wait takes a pthread_mutex argument, so it inherits any 
problems it has.  I haven't looked at pthread_cond enough to understand 
any further issues.

> I too find it unfortunate that so much functionality got stuffed into  
> pthread_mutex_t.  And that is precisely why boost::mutex, and the  
> proposed std::mutex separate out functionality into different types.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#mutex_rationale
>
>> Like boost, and unlike POSIX, this design separates these  
>> functionalities into several distinct types which form a hierarchy  
>> of concepts. The rationale for the different types is to keep the  
>> most common, and simplest mutex type as small and efficient as  
>> possible. Each successive concept adds both functionality, and  
>> potentially expense.

Absolutely.

> That being said, the posix rationale includes the following statement  
> on this issue:
>
>> Since most attributes only need to be checked when a thread is going  
>> to be blocked, the use of attributes does not slow the (common)  
>> mutex-locking case.

Yes, I noticed that.  But in the common case of locking an uncontended 
mutex, if it is recursive you need to record your thread ID in the 
mutex structure.  So you either need to check what kind of mutex you 
are or store the id unconditionally.  (Unless I have missed something.)

> David Butenhof (Programming with POSIX Threads) recommends semaphores  
> for use cases where you want to lock in one thread and unlock in  
> another.

Yes, that's a good point.  I should investigate it further.

Regards,  Phil.