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

[Jonathan Hogg]

On 4/8/2002 21:17, in article aik24g$4a3$0 at 216.39.172.122, "Bengt Richter"
<bokr at oz.net> wrote:

> 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.

[See other post about this]

> How multiple waiters are queued would be a separate matter, but presumably
> FIFO within priorities. That would depend on the OS's mutex implementation.
> 
> ISTM it would be a huge inefficiency, e.g., to make ready a thousand threads
> and let them run only to re-block except for one. ISTM that does not match
> the semantics of the GIL, and if it is happening, a mutex-like implementation
> should be simulated if not directly available. To resolve the question,
> I suppose we have to look at what OS mechanisms really are used to implement
> the GIL on various platforms.

The GIL (on pthreads) uses a "wake one" semantics on release
(pthread_cond_signal as opposed to pthread_cond_broadcast), so you wouldn't
have to worry about this - only one thread is made runnable. But, I'm not
clear on the exact semantics of this.

For instance: is the thread that was waiting on the condition that is
unblocked removed immediately from the wait list for the condition? Or only
when it actually gets scheduled?

If the OS keeps the current thread on the CPU for a reasonable timeslice
then it will run through the release-reacquire many times. If the thread it
unblocks is immediately removed from the condition wait list, then next time
through it will unblock another, and in a few thousand bytecodes it would
have unblocked every waiting thread. In which case, the "wake one" semantics
actually won't make any difference. Anyone?

Then again, it hardly matters as only one thread gets scheduled and it
immediately grabs the lock. The fact that the other threads are runnable
doesn't make any difference.

Unless, of course, you have a few thousand CPUs ;-)

Jonathan