hpx::lcos::condition_variable could be suspect to deadlocks

[sithhell]

The current code for hpx::lcos::condition_variable (and the _any variant) might lead to deadlocks.
The deadlock situation might, for example, be encountered, when concurrently calling wait.
The problem is, that the outer lock (provided from the caller) is being tried to be acquired unconditionally with the inner lock (protecting the lcos::detail::condition_variable) is being held.

[hkaiser]

I'd assume you're talking about this code: https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/lcos/local/condition_variable.hpp#L50-L65

Here, the outer lock is re-acquired in the destructor of the util::unlock_guard<> while the inner lock is still being held (and for a good reason, btw). I'm not sure what you mean by 'unconditionally' in

the outer lock (provided from the caller) is being tried to be acquired unconditionally

What condition should have been applied to that re-acquire operation?

[sithhell]

Yes, I am talking about this code. The outer lock being re-acquired while the inner lock is being held is exactly what will lead to a deadlock:

T1              | T2
================| ================
outer.lock();   | ...
inner.lock();   | ...
outer.unlock(); | ...
inner.unlock(); | outer.lock();
inner.lock()    | inner.lock();
// Assume T1 acquired inner.lock(). T2 still holds outer, once T1 tries to acuire outer.lock, we get into a deadlock situation.
outer.lock();   | ...
inner.unlock(); | ...

With "uncoditionally", I meant that we don't consider that another lock might be held when trying to acquire the other.

[brjsp]

This is a similiar issue to the one discussed in this article: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html (kindly provided by @K-ballo on IRC)