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

[Martin v. Loewis]

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?

Regards,
Martin