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 <marek.olsak@amd.com>
Reviewed-by: Gustaw Smolarczyk <wielkiegie@gmail.com>
This commit is contained in:
Nicolai Hähnle
2017-09-28 17:52:42 +02:00
parent c49400a03b
commit a208cd7ae4

View File

@@ -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);
}