22.10 Implementing Interprocess Communication Using a Mutex

 <  Day Day Up  >  

You want to synchronize execution of some protected blocks of code between threads ”but the threads are in different processes.


Technique

The general technique is similar to using a mutex to synchronize threads within one process, except that the mutex must be named and each process must instantiate a mutex object with the same name. For example, suppose we name the mutex TestMutex :

 
 Mutex mutex = new Mutex(false, "TestMutex"); 

Here we pass two parameters to the Mutex constructor. We will examine the first ( bool ) parameter soon. What interests us here is the second parameter, the mutex name. What this constructor does is cause the Windows operating system to examine its internal table of mutexes to see whether a mutex with that name already exists. (Recall that under the hood, mutexes are Windows kernel objects.) If no such mutex exists, then a new one is created. If there is already a mutex of that name, however, the CLR simply attaches the new Mutex class instance to the existing mutex. If two applications are running and both execute the preceding line of code, the end result is that they each have a Mutex object that wraps the same underlying operating-system mutex.

Now we examine that first parameter to the constructor. This bool value indicates whether the mutex should be created in a state in which it is already owned by the current thread. Note the following line:

 
 Mutex mutex = new Mutex(true, "TestMutex"); 

It is equivalent to writing the next lines:

 
 Mutex mutex = new Mutex(false, "TestMutex"); mutex.WaitOne(); 

From now on, the procedure is the same as before. In each process, you have code like this to synchronize access:

 
 mutex.WaitOne(); // protected code here mutex.ReleaseMutex(); 

Because both processes have access to the same mutex, the fact that two threads might be in different processes is completely irrelevant: The synchronization works just as if the threads were in the same process.

Comments

The ability to synchronize cross-process in this way graphically shows the real underlying power of mutexes. It also provides a useful, albeit limited, means of cross-process communication.

You do need to be careful with the choice of name for the shared mutex because there is the theoretical possibility that an unrelated process might attempt to create a mutex and by coincidence give it the same name and thereby unintentionally end up sharing your mutex. To avoid this problem, make sure that the string you choose for the name is likely to be unique. TestMutex is not a good name in production code. Choosing a Guid ”or for that matter any random string ”as a name is quite a good way to ensure uniqueness. You just need to ensure that all processes that intend to share the mutex are aware of the name, which you might choose to do by hard-coding the name.

Note that the underlying mutex kernel object remains alive until all CLR Mutex instances that refer to it are disposed or finalized. So take special care with named mutexes to ensure that you call Dispose() on them when you have finished with them.

 <  Day Day Up  >  


Microsoft Visual C# .Net 2003
Microsoft Visual C *. NET 2003 development skills Daquan
ISBN: 7508427505
EAN: 2147483647
Year: 2003
Pages: 440

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net