Parcourir la source

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`.
cypherpunks il y a 8 ans
Parent
commit
b3ea3c8e2f
2 fichiers modifiés avec 7 ajouts et 4 suppressions
  1. 3 0
      changes/bug16644
  2. 4 4
      src/common/workqueue.c

+ 3 - 0
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.

+ 4 - 4
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)