This talk of Mutexes and Monitors brings Semaphore to mind. Whats the difference between a Semaphore and Mutex/Monitor ?
-----Original Message----- From: Mike Woodring [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 12:18 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Mutex and Monitor, any difference ? That's a pretty reasonable summary. The only other thing I'd add to what the other guys said is that mutexes are also useful if you find yourself grabbing multiple locks at a time before performing updates. Anytime you have multiple pieces of code grabbing multiple locks before doing their work, you have to be *very* careful to order things so that you prevent the potential for deadlock. For example, imagine you had multiple threads transferring funds between bank accounts, and you had one piece of code that looks like this (using monitors): lock( accountX ) { lock( accountY ) { BankAccount.Transfer(accountX, accountY, 100); } } where 'accountX' and 'accountY' are just stand-ins for more dynamically determined references to two arbitrary accounts in the system. And then you had another piece of code that happens to be written like this: lock( accountY ) { lock( accountX ) { BankAccount.Transfer(accountX, accountY, 100); } } If both pieces of code ended up trying to work on the same two accounts, and timing was against you (something you should assume :-), it's possible for one thread to grab the lock for account X, another thread to grab the lock for account Y, and then both threads end up blocking on their second lock statement waiting for the other thread to release the lock their holding. Given the above code, those two threads would deadlock. And as other threads started to operate on those two accounts, they'd get stuck as well waiting for locks that will never be released. Pretty soon it looks like a 32 car pile up in a foggy tunnel at night somewhere. One solution (although not foolproof) is to carefully order your lock acquisition so that everyone that's grabing multiple locks is always grabbing them in the same order. Another solution is to use non-infinite timeouts when waiting for locks. This won't prevent the deadlock, but it will let you break out. Since the C# lock construct doesn't timeout args, you'd have to tweak your code along these lines: if( Monitor.TryEnter(accountX, SOME_TIMEOUT) ) { try { if( Monitor.TryEnter(accountY, SOME_TIMEOUT) ) { try { BankAccount.Transfer(accountX, accountY, 100); } finally { Monitor.Exit(accountY); } } else { // Deal with failure to grab lock. } } finally { Monitor.Exit(accountX); } } else { // Deal with failure to grab lock. } With mutexes, you can simply put the references to the mutexes in an array and use WaitHandle.WaitAll to grab all of the locks (or wait until such time as you can safely grab all of them). For example (where the Lock property is an accessible mutex associated with each account object): WaitHandle[] acctLocks = { accountX.Lock, accountY.Lock }; if( WaitHandle.WaitAll(acctLocks) ) { try { BankAccount.Transfer(accountX, accountY, 100); } finally { accountX.Lock.ReleaseMutex(); accountY.Lock.ReleaseMutex(); } } else { // This thread was aborted - hopefully very rare. } The CLR/OS implementation of WaitAll will ensure that your thread blocks until you can own all the locks specified, while at the same time preventing the potential for deadlock (no matter what order the references to the mutexes are placed in the wait handle array). -Mike http://staff.develop.com/woodring http://www.develop.com/devresources ----- Original Message ----- From: "Pierre Greborio" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 20, 2002 9:25 AM Subject: Re: [ADVANCED-DOTNET] Mutex and Monitor, any difference ? > Thanks to all. Then, If I need to share the synchronization mechanism > through AppDomain boundaries I need Mutex. Inside the same AppDomain > Monitor is better. > > Thanks > Pierre > > ----------------------------------------------- > Pierre Greborio > [EMAIL PROTECTED] > http://www.pierregreborio.it > ----------------------------------------------- > > > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of Craig Andera > Sent: Friday, September 20, 2002 4:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Mutex and Monitor, any difference ? > > > > I don't find any conceptual difference between Mutex and Monitor. Can > > someone tell if there are any ? > > Mutexes can be named, making them usable across process boundaries. > > Monitors have Pulse and Wait functionality, making it easier for you to > lessen the risk of thread starvation. > > I suspect that Monitors are implemented to use OS CriticalSections > wherever possible, and that Mutexes use, well, OS Mutexes. That probably > means that Monitors are more efficient, since they don't mandate a > switch into kernel mode. But I haven't spelunked the implementation, so > that's just speculation. > > But fundamentally they're both single-owner mutual-exclusion locks. > > Maybe MikeW or someone else can think of some other, more fundamental > differences. > > You can read messages from the Advanced DOTNET archive, unsubscribe from > Advanced DOTNET, or subscribe to other DevelopMentor lists at > http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
