Phil Endecott <spam_from_boost_dev <at> chezphil.org> writes:
(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.)
You're right: there wasn't one. I'll add one.
Anthony Williams wrote:
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.
Yes.
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.
Indeed. Rereading my sentence above, it is not quite as clear as I intended. Any type that implemented the appropriate interface for the concept would be "lockable" from my POV. However, "lockable" doesn't highlight for me the intent of packaging a data item with a mutex: Lockable<int> is not just a "lockable int" (i.e. "an int that can be locked") --- the intent (safe concurrent access) is more than that.
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.
Naming is tricky :-). safe_for_concurrent_access<int> is a bit long-winded.
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?
I don't know. I've been focusing on the use of specializations that really are atomic when I've been reading the papers. I'll raise the issue. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL