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: mutex lock * 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> -Howard