Author: Vincent Diepeveen
Date: 05:03:29 04/25/01
Go up one level in this thread
On April 25, 2001 at 01:37:39, Hristo wrote: >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 ;-))) but i only want to get rid of the Sleep(100); yet i do not want to let it eat up a full processor it should idle till a condition is met. It's trivial to rewrite it to 1 condition. That's a design issue. Basically i need WaitForSingleObject :) >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.