[issue8410] Fix emulated lock to be 'fair'

Kirill Smelkov added the comment: Thanks for feedback. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue8410] Fix emulated lock to be 'fair'

Kristján Valur Jónsson added the comment: super, good catch! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8410] Fix emulated lock to be 'fair'

Kirill Smelkov added the comment: At least condition variable signalling has to be moved to be done under mutex for correctness: https://bugs.python.org/issue38106. -- nosy: +navytux ___ Python tracker _

[issue8410] Fix emulated lock to be 'fair'

Changes by Kristján Valur Jónsson : -- resolution: -> rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8410] Fix emulated lock to be 'fair'

Kristján Valur Jónsson added the comment: Closing this issue. It is largely superseded. For our Python 2.7 branches, we have a custom "GIL" lock which can have different inherent semantics from the common "Lock". In particular, we can implement a "fair" PyGIL_Handoff() function to be used to

[issue8410] Fix emulated lock to be 'fair'

Changes by Ronald Oussoren : -- assignee: ronaldoussoren -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue8410] Fix emulated lock to be 'fair'

Ronald Oussoren added the comment: It turns out that posix semaphores aren't supported on OSX. The patch doesn't apply cleanly anymore, and that is not just because of whitespace issues (the patch contains tabs while the tree no longer does). The chunk that affects 'PyThread_acquire_lock_ti

[issue8410] Fix emulated lock to be 'fair'

David Beazley added the comment: I know that multicore processors are all the rage right now, but one thing that concerns me about this patch is its effect on single-core systems. If you apply this on a single-CPU, are threads just going to sit there and thrash as they rapidly context switch

[issue8410] Fix emulated lock to be 'fair'

Kristján Valur Jónsson added the comment: In 2), B is indeed signaled and the OS makes it "runnable". But it doesn´t run immediately. A is still running. There is no need for A to stop running until it runs out of timeslice. Meanwhile the OS has to put B on a separate core (which makes thi

[issue8410] Fix emulated lock to be 'fair'

Ray.Allen added the comment: Hi, krisvale: > Since the exact mechanics seem to be unclair to many, let me just step you > through the series of events. > 1) A has the lock, B is waiting for it. the bit is "set". > 2) A releases the lock: Clears the bit, signals the condition variable. > 3)

[issue8410] Fix emulated lock to be 'fair'

Kristján Valur Jónsson added the comment: Also, _POSIX_SEMAPHORES must be defined to be greater than 200112L. If it isn't, then it isn't supported. -- ___ Python tracker ___ __

[issue8410] Fix emulated lock to be 'fair'

Kristján Valur Jónsson added the comment: Is it possible that unistd.h isn't included by Python on mac builds? perhaps the config script is broken and HAVE_UNISTD_H doesn't get defined. I'll have a look at the generated pyconfig.h file on my colleague's machine tomorrow. --

[issue8410] Fix emulated lock to be 'fair'

Ronald Oussoren added the comment: W.r.t. "This appears to be the case on Mac OS X": OSX 10.4 and later seem to support posix semaphores, the program below prints "yes": #include int main() { #ifdef _POSIX_SEMAPHORES printf("yes\n"); #else printf("no\n"); #endif } --

[issue8410] Fix emulated lock to be 'fair'

Kristján Valur Jónsson added the comment: Martin, it isn't the condition variable which is unfair, but how the constructed locking apparatus is unfair that is the problem. This lock is written by a Tim, whom I assume to be Tim Peters. I quote his comment: "In general, if the bit can be acq

[issue8410] Fix emulated lock to be 'fair'

Antoine Pitrou added the comment: I don't understand why you claim your patched version is fair. As far as I can tell, if you have three threads A, B and C all routinely trying to take this lock, your implementation can perfectly well bounce between A and B without ever giving the lock to C.

[issue8410] Fix emulated lock to be 'fair'

Martin v. Löwis added the comment: > On pthreads plaforms, if the posix_sem functions aren't available > (when _POSIX_SEMAPHORES isn't defined), the python lock is > implemented with a mutex and a condition variable. This appears to > be the case on Mac OS X, for example. The problem is that th

[issue8410] Fix emulated lock to be 'fair'

New submission from Kristján Valur Jónsson : On pthreads plaforms, if the posix_sem functions aren't available (when _POSIX_SEMAPHORES isn't defined), the python lock is implemented with a mutex and a condition variable. This appears to be the case on Mac OS X, for example. The problem is that