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).
> 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk