Author: Vincent Diepeveen
Date: 05:00:44 04/25/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. > >>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. :) Oh my problem isn't so complex, the function waitformultipleobjects was just a function which i found which looks cool to me. I just want to get rid of Sleep(100); design in DIEP which wastes 100ms for every loop of the lus. The locking is not the problem. Only 1 process can set and reset those variables, the i/o thread :) > >> >>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.