Hi, On Tue, Aug 26, 2008 at 11:14:05PM +0200, Fons Adriaensen wrote: > 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.
It sounds like you're suggesting that the threading module is broken. You'd be best off taking this to the Python mailing list, I suspect, so that folks that *really* know Python can either confirm the bug, or explain what you are missing. -Forest -- Forest Bond http://www.alittletooquiet.net http://www.pytagsfs.org
signature.asc
Description: Digital signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
