How smart are Semaphore Objects?

[Ype Kingma]

Matthew,

you wrote:
> 
> I firmly believe that when coding a function, object, program or
> whatever, one should assume that every other function, ... is either
> stupid or out to get you.  With this mind-set, I'm curious as to how
> (idiot or mean-person) proof semaphore objects are.
> 
> Threading.Semaphore.
> 
> If a class can't acquire a semaphore, or doesn't bother, can it
> release it, despite not owning it?

A Semaphore can be released from an other thread.
> 
> It's almost a security thing.  I want in, and so, I will release the
> semaphore, repeatedly if necessary, until I get in.
> 
> Is the semaphore able to avoid this kind of thing?  Or do you just
> have to rely on the fact that people generally don't try to release a
> semaphore that they haven't acquired?
> 

You might prefer to use RLock. Releasing it is documented ao. by:

"Only call this method when the calling thread owns the lock.
Do not call this method when the lock is unlocked."

It can be better for performance to release a Semaphore from another thread.
I would consider this as a candidate for style improvement, though.

> This may seem a bit paranoid, but in big groups, paranoid is so
> important.  My code may be a bit large, but it's never the part that
> crashes because of a divide by 0 or a file didn't open because it
> never existed.

Nod.

> Maybe there is an exception the Semaphore raises?  I don't know.
> 

When you are paranoid enough test RLock. You'll like it.

> Thanks for helping.  I really appreciate the time and effort.

My pleasure,
Ype

-- 
email at xs4all.nl