Module: Mesa Branch: master Commit: a208cd7ae4c1613dfd9acafa6046c1cd0be4911f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=a208cd7ae4c1613dfd9acafa6046c1cd0be4911f
Author: Nicolai Hähnle <[email protected]> Date: Thu Sep 28 17:52:42 2017 +0200 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: [email protected] Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Gustaw Smolarczyk <[email protected]> --- 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 449da7dc9a..3b05110e9f 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); } _______________________________________________ mesa-commit mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-commit
