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

From: Kai Brüning (kai_at_[hidden])
Date: 2007-08-21 10:20:49

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.

Kai