From: Howard Hinnant (hinnant_at_[hidden])
Date: 2006-11-01 17:50:29
On Nov 1, 2006, at 5:10 PM, Roland Schwarz wrote:
> I have two more questions:
> 1) No mention of thread local storage. Why?
I believe it will be a language feature. My vote for keyword is
thread_local. Lawrence Crowl is taking it on.
> 2) Is the basic_lock meant to be thread safe or not?
Not. And basic_lock is really not a template class, just a concept.
<on the difference between locks and mutexes>
So one of the things I found really confusing about
boost::scoped_lock, and I only found it confusing after several
years of using it, is:
bool scoped_locked::locked() const;
Bad name. But really subtly bad. This function does not tell you if
the underlying mutex is locked or not. It tells you whether this
scoped_lock owns the mutex's locked state. locked() could answer
false and the mutex might still be locked (just by someone else). So
I think this is a better name for the same functionality:
bool scoped_locked::owns() const;
After this, at least for me, the important differences between
mutexes and locks slowly became a little clearer:
* Is construction/destruction thread safe? no no
* Is lock()/unlock() thread safe? yes no
* Is it moveable? no yes
mutex is nothing more than a handle to an OS resource (like memory).
lock is an RAII wrapper for the mutex (as smart pointers are to
memory). Unlike memory, locks handle the lock/unlock state of the
mutex, rather than the allocation/dellocation. lock is essentially
an auto_ptr to a mutex, but does lock() on construction and unlock()
on destruction. Despite the existence of lock, being able to operate
directly on the mutex is still occasionally useful (as is using new/
delete directly on heap allocated memory).
All of what I've said above is superficially obvious. But, imho, it
bears repeating and contemplation even for experienced users. It is
all too easy to confuse the role of locks and mutexes (as I have done
myself, quite recently).
</on the difference between locks and mutexes>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk