New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch Python to using native Win32 condition variables #104530
Comments
For now there's no difference because no one has bothered to modify the Windows implementation of If native condition variables are adopted, then if we ever want to support a Ctrl+C interrupt when waiting on a |
Hi @eryksun, I appreciate you looking at these changes. I had looked at the POSIX implementation of The POSIX specification details how POSIX condition variables are subject to spurious wakeup:
and how the execution of a signal handler may cause the condition variable to have a spurious wakeup:
Note in particular that this means that Win32 condition variables are likewise subject to spurious and stolen wakeups, as documented in Raymond Chen's 'Old New Thing' blog and the docs for
The C signal handler code could signal all threads waiting on the condition variable. The thread(s) waiting on it would be woken without the condition being satisfied, and so would return
The documented way to wake Given that there appears to be a natural path to implementing support for the Thanks, Andrew R |
|
Hi Eryk, Thanks for clarifying what you meant by "a particular thread" — I hadn't dug into the details of how the signalling handling worked, as the back-of-an-envelope analysis I'd done of how support for the I hope that the explanation I've given of how I think we both agree that Since semantically, any caller of In any case (to the point in your original post), if the use of Win32 condition variables and SRW locks were to be considered a performance hazard at such point in time as support for the In summary, I don't see any remaining reason to object to taking this change… Thanks, Andrew |
Two quick points:
Thanks, Andrew R |
I've started a benchmarking run for your PR. |
There was a problem. I've restarted the benchmarking run. |
So a little bit faster, but not much. |
A shame it's not more, but we have a grocery chain here in the UK whose motto is "Every Little Helps"… What do you think? Andrew R |
Py_HAVE_CONDVAR
denotes support for Python condition variable APIs. On Win32, the_PY_EMULATED_WIN_CV
macro exists to allow condition variables to be emulated using Win32 critical section and semaphore APIs.Native Win32 support for condition variables has existed from Windows Vista onwards (courtesy of my friend and fellow ex-MSFT colleague Neill Clift).
An implementation of Python condition variable also exists with
_PY_EMULATED_WIN_CV
set to0
which uses native Win32 condition variable / SRW lock (mutex) support.Since support for Windows XP was dropped as of Python 3.5, I propose moving to the native Win32 condition variable APIs, as they are more efficient and easier to maintain.
Linked PRs
The text was updated successfully, but these errors were encountered: