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

[Bengt Richter]

On 04 Aug 2002 22:54:10 +0200, martin at v.loewis.de (Martin v. Loewis) wrote:

>bokr at oz.net (Bengt Richter) writes:
>
>> A mutex should result in a context switch every time there is a release with
>> a waiter present, since the releaser would reliably fail to re-acquire.
>> Perhaps that is the way it works on BSD? That might at least partly explain
>> Jonathan's results.
>
>I doubt that. 
Why?
>
>Notice that Python-up-to-and-including-2.2 implemented the GIL (and
>all other thread.locks) using a mutex and a condition variable. I
>believe that this, in general, creates a race condition of who will
>acquire the lock when one thread releases it (both the first waiter on
>the condition, and the process who released it are runnable).
I don't believe a race condition should be possible. They are both runnable,
but the first waiter already owns the mutex at the point where they are
first both runnable (i.e., as soon as the OS has completed processing
the mutex release/handover). When the releaser gets control back from the
OS after the call to release, there is already another owner, so it can run,
but when it attempts to acquire again it will find that there is another
owner - not because the new owner was quick to execute and grab it, but
because the OS handed ownership over atomically (wrt running threads)
to an existing waiter. If the waiter has to race and grab, where is the
grabbing code? It has already requested the mutex and is just waiting
for a return with the request satisfied, IWT. (I Would Think ;-).

IOW, I don't think the new owner has to execute before it becomes owner
of the mutex, I think the OS hands it over as part of the release operation
if there is a waiter. Why would it be done otherwise?

OTOH, if there is a variable associated with the mutex that is supposed
to represent some state of the interpreter, and other threads are reading
this without synchronizing, then I can see a possible (different) race.

If a race condition is possible, I think the OS mutex implementation
is not good or more likely there's a bug in its use and/or simulation.

>
>In Python-CVS, the lock is implemented with a POSIX semaphore if
>available. The FIFO semantics of the semaphore (if implemented that
>way) become more relevant.
>
>> How multiple waiters are queued would be a separate matter, but presumably
>> FIFO within priorities. That would depend on the OS's mutex implementation.
>
>The mutex implementation is probably irrelevant - condition variable
>and semaphopore matter.
Because mutex is not used after 2.2? But I thought 2.2 was the 'business' edition.
If there's a race condition there, should it not be looked into and fixed?

>
>> ISTM it would be a huge inefficiency
>
>What is ISTM?
>
It Seems To Me ;-)

Regards,
Bengt Richter