global interpreter lock not working as it should

[Armin Steinhoff]

Jonathan Hogg <jonathan at onegoodidea.com> wrote in message news:<B970383D.EFB0%jonathan at onegoodidea.com>...
> On 2/8/2002 10:55, in article
> ddc19db7.0208020155.637f446e at posting.google.com, "Armin Steinhoff"
> <a-steinhoff at web.de> wrote:
> 
> > No ... when I follow up the discussion, it seems to be obviously that
> > most Python experts are NOT operating system experts!
> 
> Even if this were true, it would hardly matter. We aren't discussing the OS,
> we're discussing thread behaviour within Python.

OK ... but the scheduler of the OS and the used scheduling startegie
has a great impact of the behavior of Python threads.

There are well known different scheduling strategies:

FIFO, Round Robin, adadptive scheduling, sporadic scheduling (RMA)

If you run the Python interpreter with FIFO or RR scheduling ... the
following code from ceval.c make no sense, because the priority of the
interpreter is static.

#ifdef WITH_THREAD
			if (interpreter_lock) {
				/* Give another thread a chance */

				if (PyThreadState_Swap(NULL) != tstate)
					Py_FatalError("ceval: tstate mix-up");
				PyThread_release_lock(interpreter_lock);

				/* Other threads may run now */

				PyThread_acquire_lock(interpreter_lock, 1);
				if (PyThreadState_Swap(tstate) != NULL)
					Py_FatalError("ceval: orphan tstate");
			}
#endif

If you run the Python interpreter with adaptive or sporadic scheduling
.. the priority will change dynamically to a lower and higher priority
regarding the scheduling criteria.

That means, if a Python thread with a higher priority acquieres the
GIL, the running thread with the lower priority will inherit the
priority of the other thread (if priority inheritance is supported, if
not you will have the case of priority inversion ...) in order to
complete its task as soon as possible.
In such a case we will see a context switch between the realease_lock
and the acquire_lock calls.

Hope it's now clear how strong the thread behavior depends on the OS
and the used scheduling startegies.

> 
> [I'd warn you, though, that you're treading on dangerously thin ice.]

Thanks for your warning :)

Armin