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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
