Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk