26 Aug
2008
26 Aug
'08
6:18 p.m.
On Tue, Aug 26, 2008 at 09:55:07PM +0200, Arnold Krille wrote:
Did you look two lines above yours :-) :-) :-)
Yes, of course I did. It defines a Semaphore on top of
a Condition which is pure ugly hackery on top of a RLock.
Can't be correct, since AFAICS the primitives provided
by thread are not sufficient. Apart from the fact that
a sema requiring a few hundreds of lines of high-level
code can't be healthy.
The basic problem is that the lock provided by thread
is not counting: releasing it while it is not acquired
produces and error. Of course one could create a class
that contains a counter, but then the problem is to
atomically modify the counter and access the lock.
AFAICS, for this reason, whatever happens in threading
can't be correct, or at least not pre-emption and SMP
safe.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
Am Dienstag, 26. August 2008 schrieb Fons Adriaensen:
Does anyone
know of a counting semaphare class/module
in Python ? Given the lock provided by the built-in
thread module it seems impossible to implement this
(it does support multiple waiters which I don't need,
but definitely is not counting). This also means that
whatever is defined in the threading module can't be
what I want.
Did you look at the threading module? Looks as if there a Semaphore() in
there...