Semaphore or what should I use?

[Bastian Hammer]

Hi

I´m wondering why there are so few examples with Semaphore.
Is it obsolete?

I´ve got a Class Data.
It offers 2 Threads methods for updating, editing, .. a private
dictionary.

Now I have to make sure, that both threads are synchronal,
1 thread edits something and the other is blocked until the first
thread is ready.

Isn´t it a good idea to do this with a semaphore?

And if I should use a Semaphore here, could anybody give me an example
how it should look like?

Everything that I test throws errors :(

Thank you :)
Bye, Bastian

[Ville Vainio]

>>>>> "Bastian" == Bastian Hammer <we*******@haustierworld.de> writes:

Bastian> Now I have to make sure, that both threads are
Bastian> synchronal, 1 thread edits something and the other is
Bastian> blocked until the first thread is ready.

Bastian> Isn´t it a good idea to do this with a semaphore?

Semaphore will do, but this is a classical use case for
threading.Lock.

There should be lots of stuff regarding locks (or more googleably,
"mutexes") on the net.

--
Ville Vainio http://tinyurl.com/2prnb

[Pierre Barbier de Reuille]

Ville Vainio a écrit :

>>"Bastian" == Bastian Hammer <we*******@haustierworld.de> writes:

Bastian> Now I have to make sure, that both threads are
Bastian> synchronal, 1 thread edits something and the other is
Bastian> blocked until the first thread is ready.

Bastian> Isn´t it a good idea to do this with a semaphore?

Semaphore will do, but this is a classical use case for
threading.Lock.

There should be lots of stuff regarding locks (or more googleably,
"mutexes") on the net.

I don't agree. Mutexes (or locks) are best suited for critical sections
(ie. sections that cannot be run by many thread at the same time). The
kind of synchonisation Bastian want is not really semaphore either but
more event. This python "Event" object is described in the section 7.5.5
of the documentation of Python 2.3. There is no example, but I think
Event are quite strait forward : you creates it, then some thread block,
waiting the event to occure while some other thread execute until it set
the event, allowing the blocked thread to go on its own execution :)
Here a small working example :

***8<************8<***************8<**********
import threading, time

class MyThread(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
self._event = threading.Event()
self._exit = False
def run(self):
while 1:
print "Waiting for an event to continue"
self._event.wait()
print "Ok, the thread is unblocked now :)"
if self._exit:
return
self._event.clear()
def unblock(self):
self._event.set()
def exit(self):
self._exit = True
self.unblock()

t = MyThread()
t.start()
time.sleep(1)
t.unblock()
time.sleep(1)
t.unblock()
time.sleep(1)
t.exit()
***8<************8<***************8<**********
Pierre

[Sergei Organov]

Pierre Barbier de Reuille <pi************@cirad.fr> writes:

Ville Vainio a écrit :

>>>"Bastian" == Bastian Hammer <we*******@haustierworld.de> writes:

Bastian> Now I have to make sure, that both threads are

Bastian> synchronal, 1 thread edits something and the other is
Bastian> blocked until the first thread is ready.
Bastian> Isn´t it a good idea to do this with a semaphore?

Semaphore will do, but this is a classical use case for
threading.Lock.

There should be lots of stuff regarding locks (or more googleably,
"mutexes") on the net.

I don't agree. Mutexes (or locks) are best suited for critical sections (ie.
sections that cannot be run by many thread at the same time).

Please don't add even more confusion to the issue. Mutex conceptually is
designed to be used for MUTual EXclusion of access to a resource (e.g.,
a peace of data). While critical section could be implemented using
mutex, the mutex itself is more general concept. Besides, the rule of
thumb using mutexes is: "protect data, not program code."

My answer to OP's question is: use either lock (mutex) or semaphore.
I'd probably use semaphore as mutexes are usually optimized for the case
when contention probability is low (i.e., they usually shouldn't be locked
for a long time).

--
Sergei.

[Ville Vainio]

>>>>> "Sergei" == Sergei Organov <os*@javad.ru> writes:

Sergei> My answer to OP's question is: use either lock (mutex) or
Sergei> semaphore. I'd probably use semaphore as mutexes are
Sergei> usually optimized for the case when contention probability
Sergei> is low (i.e., they usually shouldn't be locked for a long
Sergei> time).

Both Mutexes and Semaphores put the thread to sleep, so I don't think
there will be a big difference.

The OP might also want to check out read/write lock. The first thing
google finds is

http://www.majid.info/mylos/weblog/2004/11/04-1.html

--
Ville Vainio http://tinyurl.com/2prnb

[Sergei Organov]

Ville Vainio <vi***@spammers.com> writes:

>> "Sergei" == Sergei Organov <os*@javad.ru> writes:

Sergei> My answer to OP's question is: use either lock (mutex) or
Sergei> semaphore. I'd probably use semaphore as mutexes are
Sergei> usually optimized for the case when contention probability
Sergei> is low (i.e., they usually shouldn't be locked for a long
Sergei> time).

Both Mutexes and Semaphores put the thread to sleep, so I don't think
there will be a big difference.

Yeah, most probably from this point of view there is no difference
(mutexes could be implemented using busy-waiting, but I don't think it's
the case). However, though I don't think it's a real issue in this
particular case either, mutexes can do fancy things with the thread that
has locked the mutex (mutex owner thread), like raising its priority to
the highest one of the threads waiting for the mutex to prevent so
called priority inversion.

There could be other subtle differences between mutex and semaphore
behavior resulting in different performance of the application. The
application correctness shouldn't be affected though.

--
Sergei.

[Josiah Carlson]

Pierre Barbier de Reuille <pi************@cirad.fr> wrote:

Ville Vainio a écrit :

>>>"Bastian" == Bastian Hammer <we*******@haustierworld.de> writes:

Bastian> Now I have to make sure, that both threads are
Bastian> synchronal, 1 thread edits something and the other is
Bastian> blocked until the first thread is ready.

Bastian> Isn´t it a good idea to do this with a semaphore?

Semaphore will do, but this is a classical use case for
threading.Lock.

There should be lots of stuff regarding locks (or more googleably,
"mutexes") on the net.

I don't agree. Mutexes (or locks) are best suited for critical sections
(ie. sections that cannot be run by many thread at the same time). The
kind of synchonisation Bastian want is not really semaphore either but
more event. This python "Event" object is described in the section 7.5.5
of the documentation of Python 2.3. There is no example, but I think
Event are quite strait forward : you creates it, then some thread block,
waiting the event to occure while some other thread execute until it set
the event, allowing the blocked thread to go on its own execution :)

You can agree or disagree as much as you want. Fundamentally, they are
all equivalent.

The only thing that makes mutex 'special' is that one can have an
optional 'call this function with this argument when it gets the lock',
but that can be implemented with a standard Lock, Condition, Event,
Semaphore, etc.
- Josiah

[Pierre Barbier de Reuille]

Sergei Organov a ecrit :

Pierre Barbier de Reuille <pi************@cirad.fr> writes:

Ville Vainio a ecrit :

>>>>"Bastian" == Bastian Hammer <we*******@haustierworld.de> writes:

Bastian> Now I have to make sure, that both threads are

Bastian> synchronal, 1 thread edits something and the other is
Bastian> blocked until the first thread is ready.
Bastian> Isn't it a good idea to do this with a semaphore?

Semaphore will do, but this is a classical use case for
threading.Lock.

There should be lots of stuff regarding locks (or more googleably,
"mutexes") on the net.

I don't agree. Mutexes (or locks) are best suited for critical sections (ie.
sections that cannot be run by many thread at the same time).

Please don't add even more confusion to the issue. Mutex conceptually is
designed to be used for MUTual EXclusion of access to a resource (e.g.,
a peace of data). While critical section could be implemented using
mutex, the mutex itself is more general concept. Besides, the rule of
thumb using mutexes is: "protect data, not program code."

My answer to OP's question is: use either lock (mutex) or semaphore.
I'd probably use semaphore as mutexes are usually optimized for the case
when contention probability is low (i.e., they usually shouldn't be locked
for a long time).

My point is : semaphore is more complex than what he needs. Event are
simpler and just do what he needs : block one thread until another one
finished some jobs and launchs the event (have a look at my example).

Afterward, I agree that the concept of mutex is the most general : you
can implement every other kind of lock using just mutexes.

Pierre