<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <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#c28">Comment # 28</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 <a class="email" href="mailto:shinji.suzuki@gmail.com" title="Suzuki, Shinji <shinji.suzuki@gmail.com>"> Suzuki, Shinji</a> <pre>Yes. I agree with you that we can do without per-sync-object if we allow all waiters enter fence_finish() freely. With that said, per-sync-object mutex has another benefit of potentially reducing lock contention among waiters on differing sync objects and with other mesa components that deals with shared resources. To be fair I also have to mention that ctx->Shared.Mutex is touched everywhere that trying to optimize in this particular context only may not make much sense and adding mutex certainly has associated overhead. Overall, I vote +1 on your strategy if free execution of fence_finish() is to be allowed. On Wed, Oct 19, 2016 at 10:21 AM, <<a href="mailto:bugzilla-daemon@freedesktop.org">bugzilla-daemon@freedesktop.org</a>> wrote: > <a href="show_bug.cgi?id=98172#c27">Comment # 27</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="show_bug.cgi?id=98172">bug 98172</a> from Michel Dänzer > > Note that if we allow concurrent fence_finish calls, I don't think we need a > per-sync-object mutex. > > ________________________________ > You are receiving this mail because: > > You reported the bug. > You are on the CC list for the bug.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>