Python threading (was: Re: global interpreter lock not working as it should)
Martin v. Loewis
martin at v.loewis.de
Sun Aug 4 22:54:10 CEST 2002
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.
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).
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.
> ISTM it would be a huge inefficiency
What is ISTM?
More information about the Python-list