Boost logo

Boost :

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]>

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk