Boost logo

Boost :

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

Phil Endecott <spam_from_boost_dev <at>> 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.

> > 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 Williams
Just Software Solutions Ltd -
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Boost list run by bdawes at, gregod at, cpdaniel at, john at