Author: Hristo
Date: 22:37:39 04/24/01
Go up one level in this thread
On April 24, 2001 at 23:54:03, Robert Hyatt wrote: >On April 24, 2001 at 22:44:22, Hristo wrote: > >>Thanks Eugene. >>However this might be a bit complicated. >>A simple case (example) is this: >>variable A has to be protected by semaphore aC (multi threading) >>variable B has to be protected by semaphore bC >>at some point in your program you want to access both >>A and B at the same time. How do you obtain a lock >>on both of them (aC and bC)? >>Well, you need to do aC.lock() and then bC.lock(). >>This is simple, not!? What if another piece of your program >>does first bC.lock() and then aC.lock()?! You are facing a chance >>of being dead locked! Tighter than a drum. > >Poor design and a known issue. Always set the locks in the same order >and this can't happen. If you set b, knowing you will eventually want to >set a, either rewrite the code or set a followed by b, even though you are >setting a well before it is needed. This function works with any type of object that can be signaled. For instance you can specify complicated conditions like: I want thread N to terminate and get a lock on semaphore A,B,C before I can continue. Normaly conditions like that can be broken down into simpler ones ... what if they can't? ;-)) You might want to share semaphores with another process. How do you know which one to lock first?! Again, this becomes a design issue.... > > >>Thread 1 just got a lock on aC, when thread 2 got a lock on bC, >>and now both threads are waiting for the other thread to release ... >>Nasty eh? >>So you use WaitForMultipleObjects(...) and it makes sure that this >>doesn't happen!!! Awesome! MS has gone a step further to actually >>provide this functionality for whole range of system wide handles >>that can be locked, signalled, flagged, etc ... Awesome functionality, >>no doubt. And this is only a simple example! >> >>WaitForMultipleObjects can help your application to be faster, and more >>maintainable. Unless you are willing to spend the time to design around >>the problems when you do not have this functionality! > > >As described, designing around it is a _good_ thing. That's a known issue >in parallel programming, and mutually-exclusive-resource-management. I've >never written code that would behave like that. Which is I guess why I >have managed to never use such a thing. :) > yeah ... if you know before-hand and understand multi-threading then things can be much cleaner and simpler! Sometimes, though, you might need for a bunch of conditions (all of them) to be satisfied for the program to continue in this case the WaitFor... helps. Sometimes WiaitForMultipleObjects is the prefered way to go ... however rare that might be. If you never needed it and have written stable multi-threaded app your design must be sound ;-))) regards. hristo > >> >>After all of this, I must admit that I despise M$ products, including all >>Windowz and anything that runs on it! ;-) The only OS I use at home >>is linux. It has been almost 4 years now that I haven't seen M$ at home. >>Please, don't consider this a flame war ... or any of that nonsense ... >>MS deserves credit in some areas, however this can not make me like them! >> >> >>cheers. >>hristo
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.