[LAD] [somewhat OT] semaphores in python

[Forest Bond]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080827/2119fbe5/attachment.pgp>