aboutsummaryrefslogtreecommitdiff
path: root/src/common/workqueue.c
diff options
context:
space:
mode:
authorcypherpunks <cypherpunks@torproject.org>2015-07-23 11:28:31 +0200
committerNick Mathewson <nickm@torproject.org>2015-08-04 13:35:02 -0400
commitb3ea3c8e2f3f49f2633c5283a886de650e3cec78 (patch)
tree4556df4e81c9159b2058cd52aeee06a1fe8406b3 /src/common/workqueue.c
parent57216275179077221978be6bad018d5e4e83c0e2 (diff)
downloadtor-b3ea3c8e2f3f49f2633c5283a886de650e3cec78.tar.gz
tor-b3ea3c8e2f3f49f2633c5283a886de650e3cec78.zip
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`.
Diffstat (limited to 'src/common/workqueue.c')
-rw-r--r--src/common/workqueue.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/src/common/workqueue.c b/src/common/workqueue.c
index 3f9a063e11..cf63634076 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)