Re: [boost] [thread] Interest in a locking pointer and lockable concept

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 
similar interfaces.

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.)

Phil.