From a208cd7ae4c1613dfd9acafa6046c1cd0be4911f Mon Sep 17 00:00:00 2001 From: =?utf8?q?Nicolai=20H=C3=A4hnle?= Date: Thu, 28 Sep 2017 17:52:42 +0200 Subject: [PATCH] util/queue: fix a race condition in the fence code MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 --- src/util/u_queue.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) 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); } -- 2.30.2