[boost] Extended lock interface [was: Boost.Threads: Do we need all those mutexes?]

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-07-15 10:36:46

Michael Glassford wrote:

> Extended lock interface
> -----------------------
> The lock interface should be extended to make it possible to determine 
> if it is locking a particular mutex. How?
> 
> Suggestions:
>    Mutex& mutex()
>    Mutex* mutex()
>    void* mutex()
>    mutex_id_type mutex()
> 
> Conclusion: ???

Can someone post a rationale for this? Not that I see the harm in adding 
it, per se, but my impression is that, if the lock exists for long 
enough that you've lost track of what it's locking, hasn't the mutex 
been locked for too long? Unless you're trying to find out from a thread 
that doesn't own the lock, which seems to be a shift of paradigm from 
the original intent. From the documentation in 
http://www.boost.org/libs/thread/doc/lock_concept.html:

"Lock objects are meant to be short lived, expected to be used at block 
scope only. The lock objects are not thread-safe. Lock objects must 
maintain state to indicate whether or not they've been locked and this 
state is not protected by any synchronization concepts. For this reason 
a lock object should never be shared between multiple threads."

As I see it, scoped locks are the physical embodiment of a critical 
section, and the longer your critical secion is, the more potential for 
it to become a bottle-neck, and the less useful concurrent programming 
will be.

-- 
Christopher Currie <codemonkey_at_[hidden]>