Re: Semaphore or what should I use?
Sergei Organov a ecrit : Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes: Ville Vainio a ecrit : "Bastian" == Bastian Hammer <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote: > > Ville Vainio a écrit : > >>"Bastian" == Bastian Hammer <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
Ville Vainio <[EMAIL PROTECTED]> writes: > > "Sergei" == Sergei Organov <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
> "Sergei" == Sergei Organov <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes: > Ville Vainio a Иcrit : > >>"Bastian" == Bastian Hammer <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
Ville Vainio a écrit : "Bastian" == Bastian Hammer <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
> "Bastian" == Bastian Hammer <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Semaphore or what should I use?
Bastian Hammer wrote:
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
Sure, you can use a Semaphore. But it sounds like you are really
wanting an exclusive lock. Semaphore can do that for you - actually
it's the default behavior. You could try using a regular old Lock.
Semaphores are locking counters. You set the counter at initialization
to some number (the default is 1). When you enter into a semaphored
area of code (using the .acquire() method), the counter attempts to
decrement and will do so if it doesn't push it beneath 0. Upon exiting
the area of semaphored code (by calling the .release() method on the
semaphore), the counter is incremented. An example would look like this:
import threading
class locking_writer:
def __init__(self, some_file):
self.sema = threading.Semaphore()
self.f = open(some_file, 'w')
def write(self, content):
self.sema.acquire()
self.f.write(content)
self.sema.release()
and used like this:
In [16]: l = locking_writer('/tmp/foo')
In [17]: l.write('test')
I haven't tested this with multiple threads, so I'll leave that up to
you if you want to use it.
Now, with all that said, the preferred way of synchronizing between
threads is to use a Queue (import Queue\nq = Queue.Queue()). If you
have a file that more than one thread needs to update, you probably want
to create a thread just to update that file and have the threads
responsible for getting information to update it with pass that
information into a queue. You may have reasons for not wanting to do
that, but it's worth looking into and considering.
Jeremy Jones
--
http://mail.python.org/mailman/listinfo/python-list
