Re: [Boost-users] owns_lock on lock not on mutex

Subject: Re: [Boost-users] owns_lock on lock not on mutex
From: gast128 (gast128_at_[hidden])
Date: 2015-10-12 15:17:58

> Knowing whether a mutex is locked is of little use, it does not tell you 
> whether you own a lock on that mutex. Not to mention that the 
> information would already be stale by the time it is returned.

Yes that's what I mean: if the mutex is locked by the calling thread,a
although again I didn't specify my self correctly. No race condition
possibility out of perspective of the calling thread

> 
> > Use case is that I have
> > private functions, which must assert that a non recursive mutex is locked.
> > The locking is already done in the public part. Why is there no such
> > function? Is there a technical reason or just overlooked?
> 
> You should reconsider your preconditions, asserting that a mutex is 
> locked makes little sense. Most likely the precondition you should be 
> looking for is whether you own a lock on said mutex instead. Here "you" 

Yes see above.

> could be anything (object instance, scope, function call, underlying 
> thread or execution agent, etc), so the mutex can't tell you that.

Mostly this is done for debugging purposes. Maybe it would a possibility to
add some extra information to the mutex. Windows critical section for
example keeps track which thread has lock it. This helps tracking down
deadlocks in the debugger. I wasn't the first one who was looking for this:
http://stackoverflow.com/questions/21892934/how-to-assert-if-a-stdmutex-is-locked