Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-21 14:37:36

On Aug 21, 2007, at 10:20 AM, Kai Brüning wrote:

> Howard Hinnant wrote:
>
>> Here is a link to a reference implementation and a FAQ for mutexes,
>> locks and condition variables I am currently anticipating proposing
>> for C++ standardization (or subsequent TR).
>>
>> http://home.twcny.rr.com/hinnant/cpp_extensions/concurrency_rationale.html
>
> I certainly like the decoupling of mutexes versus locks compared to  
> the boost design. While I think that the discipline forced by the  
> boost design is (mostly)  a good thing for users of the locking  
> primitives, it makes the creation of checking and debugging adapters  
> rather difficult.
>
> A while ago, I created a set of adapters for the CodeWarrior  
> implementation of the boost thread concepts to do debugging checks  
> and to facilitate cooperative threading for some (older) areas of  
> code. It was possible without touching the library, but depended on  
> some details of the interface and wasn't portable to the boost  
> implementation without (minor) changes.
>
> Howards proposal makes such things a lot easier and more robust by  
> two differences compared to boost.thread:
>
> - Mutexes have public lock(), unlock() etc. functions.
>
> - Lock types are orthogonal to mutex types, that is not nested in  
> and "owned" by the mutex type.
>
> The later enforces that all coding is to the lock concept only  
> without taking advantage of well-known lock implementation details,  
> which makes the introduction of lock adaptors or completely custom  
> lock objects robust.
>
> Is there any chance to refactor boost.thread in a similar way as  
> part of the ongoing rewrite? Not sure about this, but on first  
> glance it should even be possible to do this without breaking  
> existing code.

Thanks Kai.  It is all to easy to read a proposal, agree with it, and  
stay silent.  The positive comments help.  I too, would like to see  
this work merged into boost.  Going straight into boost::thread is one  
valid route.  Perhaps another is a new namespace: boost::thread::v2  
(or something like that).

-Howard