A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-March/020626.html below:

[Python-Dev] POSIX thread code

[Python-Dev] POSIX thread codeGerald S. Williams gsw@agere.com
Mon, 4 Mar 2002 10:43:40 -0500
Tim Peters [mailto:tim@zope.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
    pthread_attr_setinheritsched(&attrs, PTHREAD_EXPLICIT_SCHED);
#ifdef PTHREAD_THREAD_RR_SCHED_POLICY_SUPPORTED
    pthread_attr_setschedpolicy(&attrs, SCHED_RR);
#else /* PTHREAD_THREAD_FIFO_SCHED_POLICY_SUPPORTED */
    pthread_attr_setschedpolicy(&attrs, SCHED_FIFO);
#endif
#endif

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.

-Jerry

-O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O-
-O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661  O-
-O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592  O-




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4