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@gmail.com>