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:
@@ -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);
|
||||
}
|
||||
|
Reference in New Issue
Block a user