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.