Boost logo

Boost :

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-21 15:57:32

On Aug 21, 2007, at 3:06 PM, Roland Schwarz wrote:

> Howard Hinnant wrote:
>> Thank you for your time and comments.
> 1)
> The document speaks about both:
> a) mutex with public lock unlock and
> b) moveable locks.
> What does public lock unlock provide, that cannot be achieved with
> moveable locks also?

Mainly the ability to use user-defined locks with std-defined
mutexes. And generalizing that statement: The ability for the client
to write generic algorithms on mutexes. With the boost model if I
want this freedom, I have to work only at the lock level, and not at
the mutex level. Going up to the lock level adds inconvenience, and
does not add safety. Examples include the mutex_debug mutex adaptor
example in question 1. This can be written with the boost design but
one has to include another data member, namely: Mutex::scoped_lock, in
order to lock and unlock the mutex. In this example, nothing has been
gained by eliminating the public member functions of the mutex.
Indeed the debug adaptor now has a bigger sizeof.

Alternatively you may want to write your own mutexes, and have them
work with the std::supplied locks. This can't be done with the boost
design, because there is no standard interface for your mutex to
implement. An example user-written mutex might be:

class my::mutex
     void lock();
     bool try_lock();
     void unlock();

where my::~mutex() atomically locks itself and destructs. When
my::mutex has static storage duration this means that any threads
which owned a my::mutex at the same time static destructors are
running, will block the static destruction until the thread releases
the lock, thus (presumably) helping with an orderly shutdown. And
when you get it all working, you can just as easily say
std::unique_lock<my::mutex> lk(mut) (rather than reinventing your own
lock class when that wasn't what you were interested in).

This is much like our present day std::containers and
std::algorithms. You can write your own container and have it work
with all of the std::algorithms (as long as you follow the concepts).
And you can write your own algorithm, and it will work with the
std::containers (which meet your concepts). The public, standardized
interface to mutexes is the link allowing this kind of
interoperability between user-defined and std-defined mutexes and locks.

> 2)
> The example in Q2 uses a statically initialized mutex, but the
> reference
> implementation shows the mutex has a ctor. How is this supposed to be
> made thread-safe?

The current feeling on the committee is that function-local statics
will initialize in a thread safe manner. This hasn't made it into the
working paper yet, but I believe it soon will (perhaps as early as
this October).


Boost list run by bdawes at, gregod at, cpdaniel at, john at