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 won't help. You can try your luck with an "extension module (written
in C) using the macros Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS to
release/acquire the GIL before/after an external blocking call".
rewrite in /perl/ is probably faster: There's a thread-safe
Thread::Semaphore :-X
#robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAki0pV4ACgkQeVUk8U+VK0K4BwCfRmVcznGqScJ4ixbU6qOIoReo
+lwAoIc/b2F/mRmeL3PmJ7pRgP7xBq/H
=3hjS
-----END PGP SIGNATURE-----