This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v22: ntdll: wake up SRWLOCK waiters by thread id
ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v21: ntdll: wake up SRWLOCK waiters by thread id
ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v20: ntdll: wake up SRWLOCK waiters by thread id
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
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