On 10/12/2015 2:04 PM, gast128 wrote:

Agustín K-ballo Bergé writes:

...

On 10/12/2015 6:03 AM, gast128 wrote:

...

there is an owns_lock on the lock type but not on the mutex. This is quite unhandy. Any reason why?

A mutex could never own a lock on itself. The owner of a lock is the one responsible for calling unlock on it.

Regards,

Ok I should have expressed myself better: there seems to be no function to query a mutex if it is locked (e.g. no 'is_locked').

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.

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" could be anything (object instance, scope, function call, underlying thread or execution agent, etc), so the mutex can't tell you that. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

On 10/12/2015 4:17 PM, gast128 wrote:

...

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

...

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.

For debugging purposes, you could try creating your own `mutex` wrapper that keeps track of the calling `thread::id`. Note that access to this extra information is potentially concurrent, so you will need to synchronize it internally.

I wasn't the first one who was looking for this: http://stackoverflow.com/questions/21892934/how-to-assert-if-a-stdmutex-is-l...

That looks like an obvious attempt to misuse the existing facilities. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

Mikael Olenfalk writes:

On Mon, Oct 12, 2015 at 11:03 AM, gast128 wrote:Hello all, there is an owns_lock on the lock type but not on the mutex. This is quite unhandy. Any reason why?

The headers:

  boost/thread/testable_mutex.hpp   boost/thread/is_locked_by_this_thread.hpp

Might be what you are looking for. They do not seem to be documented so I do not know of their status.

Yes this seems what I need; possibly to use the test_mutex only in debug.

On Tue, Oct 13, 2015 at 3:32 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

Le 12/10/15 22:06, Mikael Olenfalk a écrit :

...

The headers:

boost/thread/testable_mutex.hpp boost/thread/is_locked_by_this_thread.hpp

Might be what you are looking for. They do not seem to be documented so I do not know of their status.

Please, don't use non-documented functions/classes :( This class and functions are flawed.

Vicente

Aside from the fact that testable_mutex.hpp doesn't work with recursive_mutex, what is wrong with it? /M