From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-03-17 08:59:22
klaus triendl wrote:
> is there any interest in something like a locking pointer and a type
> that I call "lockable" that pairs any type with a mutex?
> Inspired by Andrei Alexandrescu's article "volatile - Multithreaded
> Programmer's Best Friend" on ddj I implemented a concept similar to a
> locking pointer called "lock_acquirer" that collects acquisition of a
> mutex and a volatile cast of the locked type. It is even more threadsafe
> to use than a locking pointer.
> Additionally I made a class "lockable" that pairs a (volatile) type with
> a mutex type, wrapping both in a distinct type, which has first the
> advantage that the type to protect and the mutex are glued together, and
> second that it encapsulates volatile qualifier correctly.
I've mentioned something like this here a couple of times; did you see
my Proto review? http://thread.gmane.org/gmane.comp.lib.boost.devel/171620
My feeling is that the basic Lockable<T> that pairs a mutex with the
data that it locks is by itself too trivial for Boostification. Where
it gets interesting is when you provide an interface to do automatic
locking and unlocking, i.e. your locking pointer; I'd be interested to
see some example usage for your version. In my case I found that the
locking pointer (or locking reference) was actually more verbose than
explicitly locking the mutex and accessing the data, so the only
benefit is that the locking can be mandatory. But normally the only
"enforcement" that I need is a comment: /* lock this before writing
that */. Perhaps you have something more concise than I managed.
Something else to consider is the interaction with atomic operations
and lock-free data structures. It would be great if Locked<int> and
Atomic<int>, or Locked<list<int>> and lockfree_list<int>, had very
I have also previously mentioned the benefit of placing the mutex and
the data nearby in memory for performance reasons; this is an argument
in favour of Lockable<T>.
I notice that Anthony Williams used the term "lockable concept" in the
Boost.Threads release notes that he posted here recently. Anthony,
would it be possible to say e.g. "mutex concept" in your context so
that we can keep the term "lockable" available for something like
this? (Or maybe they are actually the same thing. Hmmm.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk