fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-01-15 03:00:18 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

util/queue: fix a race condition in the fence code

Browse source 
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>
(cherry picked from commit a208cd7ae4)
This commit is contained in:
Nicolai Hähnle 2017-09-28 17:52:42 +02:00 • committed by Emil Velikov
parent 7bedb1fd12
commit eac6932c66
1 changed files with 13 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
src/util/u_queue.c
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);
}