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

[Bengt Richter]

On Mon, 05 Aug 2002 18:43:24 +0100, Jonathan Hogg <jonathan at onegoodidea.com> wrote:

>On 5/8/2002 17:33, in article
>mailman.1028565444.27880.python-list at python.org, "Tim Peters"
><tim.one at comcast.net> wrote:
>
>> There's also an historic reason for the way the pthreads lock works:  at the
>> time I wrote that, the pthread spec was very young and undergoing rapid
>> change.  At the time, a pthread mutex was never intended to be held for an
>> appreciable time -- it was widely believed that a busy loop was an
>> appropriate implementation.  For that reason, the Python code is careful
>> never to hold the mutex across more than just a few very small C statements.
>> Mutexes got fancier over the years, but that design still seems a good one.
>
>Aha, now that's interesting. So do you think it would be safe to use a
>regular mutex now?
>
>I was considering trying it, but I wasn't sure if there was a Very Good
>Reason not to.
>
It looks to me like there will be the same race between releaser and newly
awakened waiter (assuming something doesn't happen to give the waiter a boost
and predetermine the race outcome), but it might simplify the code, if that
race is still deemed acceptable.

The real question before making changes, though, is what was the design intent
for relationships between threads competing for the GIL, and particularly at
the point where the check interval of byte codes counts down. E.g., if that counter
could be zapped when I higher priority thread blocks on the GIL, I guess that would
help with the priority inversion you were talking about in your other post.

Oops. Gotta run...

Regards,
Bengt Richter