[RFC PATCH v1 2/3] core/thread: Fix undefined behavior in the C++ mutex implementation

[Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>]

The current C++ mutex implementation is undefined behavior, specifically
in the cond_wait() function because std::unique_lock<std::mutex> is
constructed with std::defer_lock while the same thread has acquired the
lock. Also, right after that defer_lock, std::condition_variable calls
wait() with a unique lock, not in a locked state.

In such a situation, the correct construction is using std::adopt_lock.
However, using std::adopt_lock leads to another issue. The issue is the
lock will be released upon return in the cond_wait(). To solve the
problem, introduce a new helper function, __cond_wait() which will
release the lock with std::adopt_lock and then call it from cond_wait().
The cond_wait() then acquires the lock again before it returns. The
result is that we correctly fulfill the __must_hold() semantic while
conforming to the C++ mutex implementation.

Signed-off-by: Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>
---
 core/thread.cc | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/core/thread.cc b/core/thread.cc
index 2ff81e5..54e06e7 100644
--- a/core/thread.cc
+++ b/core/thread.cc
@@ -181,13 +181,22 @@ int cond_init(struct cond_struct **c)
 	return 0;
 }
 
-int cond_wait(struct cond_struct **c, struct mutex_struct **m)
+static int __cond_wait(struct cond_struct *c, struct mutex_struct *m)
 {
-	std::unique_lock<std::mutex> lock((*m)->mutex, std::defer_lock);
-	(*c)->cond.wait(lock);
+	std::unique_lock<std::mutex> lock(m->mutex, std::adopt_lock);
+	c->cond.wait(lock);
 	return 0;
 }
 
+int cond_wait(struct cond_struct **c, struct mutex_struct **m)
+{
+	int ret;
+
+	ret = __cond_wait(*c, *m);
+	mutex_lock(m);
+	return ret;
+}
+
 int cond_signal(struct cond_struct **c)
 {
 	(*c)->cond.notify_one();
-- 
Alviro Iskandar Setiawan