Re: [LAD] [somewhat OT] semaphores in python

From: Fons Adriaensen <fons@email-addr-hidden>
Date: Wed Aug 27 2008 - 00:14:05 EEST

On Tue, Aug 26, 2008 at 11:02:37PM +0200, Dominic Sacré wrote:

> Is this really an issue in Python? The Python interpreter is not thread safe
> anyway, there's a global interpreter lock that must be held by any thread
> accessing Python objects.
> Depending on what you're trying to do, this might be one of Python's biggest
> disadvantages, but as far as I can see, you don't need to worry about "true"
> concurrency, simply because it can't happen.

At first it would seem that solves the problem.
But AFAICS it doesn't.

A condition variable consists of

- one or more state variables, on wich a condition is defined,
- a mutex M to protect these variables from concurrent acceess,
- a binary sema S (or equivalent) on which to wait until the
  condition is satisfied.

To make all of this work correctly in all conditions, the
essential part is that one can do [wait (S), release (M)]
atomically.

A counting sema is just one special case of this, the
condition being _count > 0, where _count is an integer
and the only state variable.

The lock provided by the built-in thread module can play
the role of both M and S, and that is indeed how Condition
in threading is implemented (it's a bit more complicated,
supporting multiple waiters, but that doesn't change the
basic way it works).

BUT: the python interpreter will release the GIL every
so many bytecode instructions. There is AFAICS nothing
that would prevent it from doing this in between the two
operations that have to be atomic - it doesn't know they
have to be.

Ciao,

-- 
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Aug 27 04:15:01 2008

This archive was generated by hypermail 2.1.8 : Wed Aug 27 2008 - 04:15:01 EEST