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