Tim Peters [mailto:email@example.com] wrote:
They could be hugely better on Linux, but I don't know: there's anecdotal evidence that Linux scheduling of threads competing for a mutex can get itself into a vastly unfair state. Provided Linux implements semaphores properly, sempahore contention can be tweaked (and Python should do so), as befits a realtime gimmick, to guarantee fairness (SCHED_FIFO and SCHED_RR).
I submitted patch request 525532 that will enable semaphore use in thread_pthread.h if _POSIX_SEMAPHORES is defined. It includes proper checking of error codes and looping if EINTR is received (as you rightly pointed out). I didn't add any specific checks for a keyboard interrupt. Checks could be added in the loop for specific platforms as needed.
I'm not sure if this is an issue anyway. To quote the POSIX standard (ISO/IEC 9945-l: 1996 aka ANSI/IEEE Std 1003.1, 1996 Edition): If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread shall resume waiting for the mutex as if it was not interrupted. and: If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread shall resume waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup.
(Spurious wakeup of cond_wait is another whole can of worms.)
I haven't done much mucking around with scheduling policies under UNIX, but the only portable way I found to modify the way semaphores contend is to change the thread scheduling policy.
I have a patchfile for that as well. It mostly boils down to adding the following code before the thread is created:
# ifdef USE_EXPLICIT_SCHED
# ifdef PTHREAD_THREAD_RR_SCHED_POLICY_SUPPORTED
# else / PTHREAD_THREAD_FIFO_SCHED_POLICY_SUPPORTED /
Although as you see it requires some code to decide whether to use explicit round-robin or FIFO scheduling at all. Not all platforms allow SCHED_RR to be supported. This probably ought to be determined in the configure script. I created the PTHREAD_THREAD_*_SCHED_POLICY_SUPPORTED defines as a way to specify this.
I think this should be treated as a separate patch, since the current code doesn't specify any scheduling policies.
-O Gerald S. Williams, 22Y-103GA : mailto:firstname.lastname@example.org O- -O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O-