Python threading (was: Re: global interpreter lock not working as it should)

[Jonathan Hogg]

On 9/8/2002 9:18, in article j4znvwjvh6.fsf at aramis.informatik.hu-berlin.de,
"Martin v. Löwis" <loewis at informatik.hu-berlin.de> wrote:

> DIG <dig.list at telkel.net> writes:
> 
[...]
> 
> In a real-time application, things to do have deadlines, however, it
> is not necessary to switch forth and back between threads to meet the
> deadlines. Instead, the scheduler should priorize the "most important"
> things - which is a science on its own.
> 
>> As Dave said in [7], the big question is: how this patch would
>> affect existing applications (if applied) ? The same question, I
>> suppose, is asked before ANY change in python interpreter.
> 
> The big question is: where is the need for such a feature?

It depends on the (mis-)feature in question. I think simply increasing the
switching frequency by forcing indiscriminate yields is a poor idea - as you
note above, the scheduler should be left to make these decisions. However,
Python already defeats the scheduler because of the GIL. The question is:
can we minimise this existing effect?

If your threaded application mostly does nothing - and by this I mean the
CPU utilisation is low - then you don't have to worry too much about latency
as chances are that you're asleep when a thread is woken to respond to I/O,
and that thread will grab the lock and all's well. But if your application
tries to keep the CPU utilisation near 1.0 then there is a strong likelihood
that you will suffer (possibly unacceptable) latency dealing with I/O (or
timer interrupts, or whatever).

If you're using dynamic priority scheduling (as is likely) then you will get
bounded priority inversions all the time, but - after bumbling around for a
while - the scheduler will manage to align the planets such that your I/O
can be processed. If you try to use static realtime scheduling, then there
is a chance that you'll hit a more serious unbounded priority inversion.

Unfortunately, being the "most important" thing doesn't necessarily mean
being able to make progress in Python. Thus, I think there is an argument to
be made for examining the interaction between the GIL and the native
scheduler and seeing if a different implementation might get in the way
less.

I've not looked closely at the new POSIX semaphore implementation of the
GIL, so I don't know how that will function. But certainly the current POSIX
condition-variable implementation can exhibit worst-case behaviour in some
situations.

Jonathan