[tor-commits] [tor/master] Switch order of unblocking threads and releasing the mutex.

[nickm at torproject.org]

commit b3ea3c8e2f3f49f2633c5283a886de650e3cec78
Author: cypherpunks <cypherpunks at torproject.org>
Date:   Thu Jul 23 11:28:31 2015 +0200

    Switch order of unblocking threads and releasing the mutex.
    
    According to POSIX, the mutex must be locked by the thread calling the signal
    functions to ensure predictable scheduling behavior.
    
    Found the issue using Helgrind which gave the warning `dubious: associated lock
    is not held by any thread`.
---
 changes/bug16644       |    3 +++
 src/common/workqueue.c |    8 ++++----
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/changes/bug16644 b/changes/bug16644
new file mode 100644
index 0000000..f7126bd
--- /dev/null
+++ b/changes/bug16644
@@ -0,0 +1,3 @@
+  o Minor bugfixes (relay):
+    - Unblock threads before releasing the mutex to ensure predictable
+      scheduling behavior. Fixes bug 16644; bugfix on 0.2.6.3-alpha.
diff --git a/src/common/workqueue.c b/src/common/workqueue.c
index 3f9a063..cf63634 100644
--- a/src/common/workqueue.c
+++ b/src/common/workqueue.c
@@ -293,10 +293,10 @@ threadpool_queue_work(threadpool_t *pool,
 
   TOR_TAILQ_INSERT_TAIL(&pool->work, ent, next_work);
 
-  tor_mutex_release(&pool->lock);
-
   tor_cond_signal_one(&pool->condition);
 
+  tor_mutex_release(&pool->lock);
+
   return ent;
 }
 
@@ -345,10 +345,10 @@ threadpool_queue_update(threadpool_t *pool,
   pool->update_fn = fn;
   ++pool->generation;
 
-  tor_mutex_release(&pool->lock);
-
   tor_cond_signal_all(&pool->condition);
 
+  tor_mutex_release(&pool->lock);
+
   if (old_args) {
     for (i = 0; i < n_threads; ++i) {
       if (old_args[i] && old_args_free_fn)