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.