Re: [PATCH v17 0/2] MR3504: ntdll: An implementation of SRWLOCK that closer matches Windows'.
On Thu Aug 31 17:45:59 2023 +0000, Zebediah Figura wrote:
That's kind of surprising; win32 futexes are fair and we're using them internally. Why aren't our SRW locks fair? So it's only unfair for a very specific test. It's a simple test where I just have threads constantly acquiring and releasing exclusive SRWLOCKs in s loop. What I observed is threads can loop back and immediately re-acquire the lock after releasing it, causing one thread at a time to dominate the lock.
This cannot happen with this MR. But if I make the change to allow it, this MR would get a lot faster. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_44021
On 8/31/23 15:35, Yuxuan Shui (@yshui) wrote:
On Thu Aug 31 17:45:59 2023 +0000, Zebediah Figura wrote:
That's kind of surprising; win32 futexes are fair and we're using them internally. Why aren't our SRW locks fair? So it's only unfair for a very specific test. It's a simple test where I just have threads constantly acquiring and releasing exclusive SRWLOCKs in s loop. What I observed is threads can loop back and immediately re-acquire the lock after releasing it, causing one thread at a time to dominate the lock.
The releasing thread can re-acquire that even if there are active waiters? If that is the case and not the case on Windows, that is probably not quite "fairness" but rather scheduling correctness issue?
participants (2)
-
Paul Gofman -
Yuxuan Shui (＠yshui)