owns_lock on lock not on mutex
Hello all, there is an owns_lock on the lock type but not on the mutex. This is quite unhandy. Any reason why? Use case is in base-derived idiom: class Foo { public: void Process() { boost::unique_lock<boost::mutex> lck(m_mtx); Update(); } protected: void Update() { ++m_n; } boost::mutex m_mtx; int m_n; }; class Bla : public Foo { public: void Process() { boost::unique_lock<boost::mutex> lck(m_mtx); Update(); } private: void Update() { assert(m_mtx.owns_lock()); ++m_n2; Foo::Update(); } int m_n2; };
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, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
Agustín K-ballo Bergé <kaballo86 <at> hotmail.com> 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'). 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?
On 10/12/2015 2:04 PM, gast128 wrote:
Agustín K-ballo Bergé <kaballo86 <at> hotmail.com> 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
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-l...
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
On Mon, Oct 12, 2015 at 11:03 AM, gast128 <gast128@hotmail.com> 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. /M
Mikael Olenfalk <mikael.olenfalk <at> gmail.com> writes:
On Mon, Oct 12, 2015 at 11:03 AM, gast128 <gast128 <at> hotmail.com> 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.
Le 12/10/15 22:06, Mikael Olenfalk a écrit :
On Mon, Oct 12, 2015 at 11:03 AM, gast128 <gast128@hotmail.com> 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.
Please, don't use non-documented functions/classes :( This class and functions are flawed. Vicente
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
participants (4)
-
Agustín K-ballo Bergé -
gast128 -
Mikael Olenfalk -
Vicente J. Botet Escriba