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.
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?
-
Paul Gofman -
Yuxuan Shui (＠yshui)