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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-03-17 13:42:46

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