How smart are Semaphore Objects?

[Ype Kingma]

"Matthew D. Wood" wrote:
> 
> Ype Kingma <ykingma at accessforall.nl> wrote in message
> 
> > A Semaphore can be released from an other thread.
> 
> That sucks.
> 
> 
> > You might prefer to use RLock. Releasing it is documented ao. by:
> 
> The reason I wanted to use a semaphore, instead of a (lock or Rlock)
> was the counting ability.  I'm trying to limit my number of threads to
> say 50.  You can't do that with an Rlock, right?
>
> Hmmmm.  Maybe a condition with an Rlock...  I will have to look.
> 

You might use a semaphore initialized with 50 permits to let no more
than 50 threads in at a time. Seriously: what would you do when your threshold
is reached? Throw an exception that a serious attacker would catch anyway?

The number of threads needed normally depends on things outside
your program:
- how good are the various schedulers (OS/application-thread)?
- how many (in)dependent I/O requests must be served?
- how many processors are available?
- how many synchronisation points should be used?

> > It can be better for performance to release a Semaphore from another thread.
> > I would consider this as a candidate for style improvement, though.
> 
> I don't understand.  Why would it be better for a non-owning thread to
> release a Semaphore?

Because the second thread happens to be running and there is no time to
to wake up the first one and perform a thread switch to it.

A semaphore is not owned by a thread. A semaphore allows a maximum number of
threads to be in a (critical) section of code.
A lock is owned by a thread.

[snip]

> > > Maybe there is an exception the Semaphore raises?  I don't know.
> > >
> >
> > When you are paranoid enough test RLock. You'll like it.
> 
> Like I said, RLock seems like a 1 or 0 thing.  I need a less than
> MAX_THREADS thing.
> 

In case your threads are non cooperative (eg. in dealing
with the semaphore I suggested above) there is nothing you can do
about that in Python.

[snip]