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

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-03-17 13:10:20

Anthony Williams wrote:
> Phil Endecott <spam_from_boost_dev <at> chezphil.org> writes:
>
>> 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.)
>
> I've used the concept "lockable" to describe something which can be locked. I
> felt this was a better term than "mutex", since some of the things that can be
> locked are not mutexes. For example unique_lock<some_mutex> also models
> "Lockable", so you can have a unique_lock<unique_lock<some_mutex> >.

OK, that makes sense.

> Hopefully
> the new boost.thread docs will give you a better idea.

(Off-topic: in the release notes that you posted yesterday, I didn't 
see a sentence saying the changes are to make Boost.Threads closer to 
the std::thread proposal.)

> I would not describe a pair of data+mutex as "lockable" unless you could indeed
> lock it and unlock it (with lock()/unlock() member functions).

Well you can do exactly that if you have something like

template <typename T, typename MUTEX_T = mutex>
class Lockable: public T {
   MUTEX_t mut;
public:
   void lock() { mut.lock(); }
   void unlock() { mut.unlock(); }
};

Or even inherit from T and MUTEX_T.

I think I'm starting to like this idea.  If Lockable<T> models your 
"lockable concept", then it can be used with the multi-lock algorithm 
and so on.

> However, even if
> you could, the term "lockable" wouldn't (in my view) describe what the combined
> data structure was.

I would disagree, but it just comes down to how we have individually 
come to use these informal terms.

> Would "protected" better describe the intent? I know it's a
> keyword, but surely the idea is to protect the data from concurrent access.

Well, "protected" doesn't actually say the "...from concurrent access" 
bit.  It could be protected from anything.  Synchronized is a bit 
better (though I'd need a #define to let me spell it right :-)).  I'd 
still vote for Lockable though.

>> 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.
>
> The C++0x atomic<> template will work with any type that is "trivially copy
> assignable and bitwise equality comparable", and it is intended that operations
> are protected with a mutex where they cannot be done with atomic ops. The
> is_lock_free() member distinguishes the two cases. I would expect this to cover
> many uses, though obviously you can't write atomic<list<int>>, since list<> is
> definitely not bitwise equality-comparable.

Why have the "trivially copy assignable and bitwise equality 
comparable" restriction, if using a mutex is an acceptable solution?

Cheers, Phil.