From: Nicolai Hähnle Date: Thu, 28 Sep 2017 15:52:42 +0000 (+0200) Subject: util/queue: fix a race condition in the fence code X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=a208cd7ae4c1613dfd9acafa6046c1cd0be4911f;p=mesa.git util/queue: fix a race condition in the fence code A tempting alternative fix would be adding a lock/unlock pair in util_queue_fence_is_signalled. However, that wouldn't actually improve anything in the semantics of util_queue_fence_is_signalled, while making that test much more heavy-weight. So this lock/unlock pair in util_queue_fence_destroy for "flushing out" other threads that may still be in util_queue_fence_signal looks like the better fix. v2: rephrase the comment Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Marek Olšák Reviewed-by: Gustaw Smolarczyk --- diff --git a/src/util/u_queue.c b/src/util/u_queue.c index 449da7dc9ab..3b05110e9f8 100644 --- a/src/util/u_queue.c +++ b/src/util/u_queue.c @@ -120,6 +120,19 @@ void util_queue_fence_destroy(struct util_queue_fence *fence) { assert(fence->signalled); + + /* Ensure that another thread is not in the middle of + * util_queue_fence_signal (having set the fence to signalled but still + * holding the fence mutex). + * + * A common contract between threads is that as soon as a fence is signalled + * by thread A, thread B is allowed to destroy it. Since + * util_queue_fence_is_signalled does not lock the fence mutex (for + * performance reasons), we must do so here. + */ + mtx_lock(&fence->mutex); + mtx_unlock(&fence->mutex); + cnd_destroy(&fence->cond); mtx_destroy(&fence->mutex); }