<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters."
href="https://bugs.freedesktop.org/show_bug.cgi?id=98172#c14">Comment # 14</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters."
href="https://bugs.freedesktop.org/show_bug.cgi?id=98172">bug 98172</a>
from <span class="vcard"><a class="email" href="mailto:shinji.suzuki@gmail.com" title="shinji.suzuki@gmail.com">shinji.suzuki@gmail.com</a>
</span></b>
<pre>I've ben running tests with changes derived from your patch, with and without
random sleeps to give some shake-ups to execution order with, and have seen no
crashes so far. The differences from yours are;
* No mutual exclusions in ctor/dtor functions. (I see no chance of race in ctor
and dtor should be called only by the thread that eliminated the last
reference.)
* Locking duration is made slightly shorter.
Now I feel sufficiently convinced about the correctness of the fix and at the
same time feels that alternative implementation may better be given
consideration. As I wrote previously locking on so->Shared.Mutex introduces
contention that is not essential. Allowing concurrent calls, in relative to the
sync object at hand, to fence_finish() will require more careful implementation
from underlining gpu specific drivers, though r600 implementation seems good,
and running the same check by multiple threads seems inefficient. I'll attach
patch for an alternative implementation as well.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>