New submission from Stephan R.A. Deibel: In acquire_timed in _threadmodule.c (used to implement threading lock acquire()) there is an optimization from https://github.com/python/cpython/commit/e75ff35af2b6c85d48c68b95f295aeac7396b162 that says it first tries non-blocking lock w/o releasing the GIL. However, it seems that this call can block on Windows.
The call to PyThread_acquire_lock_timed(lock, 0, 0) (w/o releasing GIL) on Windows calls EnterNonRecursiveMutex which in turn, in the _PY_USE_CV_LOCKS impl, immediately calls PyMUTEX_LOCK as if it's not going to block. However, various implementations of this seem like they can block. Specifically, the impls of PyMUTEX_LOCK that end up using AcquireSRWLockExclusive and EnterCriticalSection both block. The only case that is correct (does not block) is when !_PY_USE_CV_LOCKS where EnterNonRecursiveMutex() instead calls WaitForSingleObjectEx() with the zero timeout. This seems like an incorrect potential for GIL deadlock, because the thread blocks without releasing GIL. Shouldn't it ultimately be using TryAcquireSRWLockExclusive and TryEnterCriticalSection in these two cases? This seems like an issue on Windows only. The pthreads implementations look like they correctly handle timeout of 0 sent to PyThread_acquire_lock_timed(). ---------- components: Library (Lib), Windows messages: 296088 nosy: paul.moore, sdeibel, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Potential for GIL deadlock on Windows in threadmodule acquire_lock type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30676> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
