Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-09-09 08:15:01

On Sep 9, 2005, at 5:32 AM, Ion Gaztañaga wrote:

> Do you have more information about these concepts and their use? It
> seems quite interesting for thread proposals.

The "performance testing" link off of the above page has example code:

> Currently in boost we have
> the following:
> scoped_lock, scoped_try_lock, scoped_timed_lock

Right. And I went this route too (following boost's lead). But
hindsight is 20/20. ;-) The scoped_lock, scoped_try_lock, and
scoped_timed_lock concepts are all strict supersets of one another (and
this is good). You can code a scoped_timed_lock, templated on the
mutex type, and use it only as a scoped_lock with absolutely zero
penalty. There is no extra data associated with a scoped_timed_lock
over a scoped_lock. And the code associated with timed locking isn't
instantiated unless you use it.

Said another way, you can get rid of the template classes scoped_lock
and scoped_try_lock, and rename scoped_timed_lock to scoped_lock, and
then use this new "combined" scoped_lock for all three uses. You will
pay no penalty in code size or speed, and you will cut your source code
maintenance by a factor of 3.

If you instantiate this new "combined" scoped_lock with a mutex that
can not execute a timed_lock (for example), absolutely no harm is done
... unless of course the client of this instantiation actually tries to
call timed_lock, in which case you would quite naturally get a compile
time error.

Analogy: std::vector doesn't require a default copy constructor of its
contained type, unless you actually instantiate certain member
functions of vector.

My scoped_lock doesn't require the mutex to have a timed_lock() member
unless you instantiate the timed_lock() member of the scoped_lock.

So my scoped_lock is simply the boost scoped_lock, scoped_try_lock,
scoped_timed_lock rolled into one class.

> Your web talks about upgradeable, shareable, so maybe we could think
> about this when thinking about C++ threading interface.

The rw_perf.html page gives motivation for the read/write - renamed to
scoped/sharable - and for adding the upgradable concept as well. The
sharable and upgradable locks all meet your scoped/try/timed concepts,
but do not demand these concepts of the mutex.

> I suppose Kevlin
> Henney is thinking about this issues regarding its C++ Threading
> interface proposal, so maybe these concepts are interesting.
> Alexander Terekhov's algorithm seems interesting, so we decide to go
> ahead with this, we should implement it on top of some boost atomic
> primitives.

<nod> See the performance link for a few notes on this (but there is no
implementation posted there, only notes).


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