Mutex Class

The next class in our list, Mutex, can be thought of as a more powerful version of Monitor. Like AutoResetEvent and ManualResetEvent, it is derived from WaitHandle. An advantage of Mutex over Monitor is that you can use the methods from WaitHandle such as WaitOne. A disadvantage is that is much slower, at about half as fast as Monitor. Mutex is very useful when you must control access to a resource that could be accessed through multiple processes, like a data file used by several applications you have created. To write to the file, the writing thread must have total access to the file throughout the operating system.

When you create a Mutex, you can assign it a name. If the name exists anywhere in the operating system then that Mutex object instance will be returned. This is the reason why Mutex is slower, also. The system must be checked to see if the Mutex already exists. If it doesn’t exist, a new one is created. When the last thread in the operating system that references the named Mutex terminates, the Mutex is destroyed. The following code example shows how to use a Mutex to control access to a file.

Private Sub btnAquireMutex_Click(ByVal sender As _
System.Object, ByVal e As System.EventArgs) Handles
btnAquireMutex.Click()
Dim mutexFile As Mutex
mutexFile = New Mutex(False, "Mutex Name")
mutexFile.WaitOne() 'Wait until the file is open
Console.WriteLine("Mutex was released from another process")
'Now I know that I have explicit access to the file
'I can write to it now.
mutexFile.ReleaseMutex()
End Sub

Let’s examine the first program. A Mutex called mutexFile is created. Internally to the operating system, we name the mutex “Mutex Name”. This is the name that will be used to resolve any other calls to the same mutex from any other application that we create. On a form we have two buttons. For demonstration purposes, one button will acquire a lock on the resource, in this case the file, using the Mutex and the other button will release the lock. This simulates a long running process on the file. As with the other synchronization classes, you should make sure to call RelaseMutex sometime after a lock is acquired or a block on the resource will occur.

The second program is very straightforward. We create a Mutex object called fileMutex making sure we have named it the same as in the first program, “Mutex Name”. If this is not done the Mutex classes will refer to different mutexes in the operating system. Then WaitOne is called without a timeout value. This will make the thread wait until the Mutex has been released. When the release button is clicked in the first program, the second can continue running since it can now acquire access to the resource. Mutex was released from another process is printed in the output window. You can also close the first program and the lock will be released. When a thread exits that has a Mutex lock on a resource, ReleaseMutex is automatically called for you.

In summary, remember that Monitor should be used most of the time. It is faster than a Mutex. Mutex should only be used when you need to synchronize across multiple processes to gain access to a common resource among several programs that you have written. Even though Mutex allows for the wait methods where Monitor does not, the other WaitHandle classes should be considered before Mutex if you need the wait methods first.

In this edition in the popular series, the Rails-to-Trails Conservancy presents the best of the Great Lakes rail-trails, home to the most rail-trails in the country. With 113 rural, suburban, and urban trails threading through nearly 2300 miles, Rail...

by suman.padda (0 replies)

by RationalMindset (6 replies)

Published 7 years ago, running time 0h20m

In this episode I'll show you an experimental API prototype I created which allows you to invoke a workflow as a task using System.Threading.Task. The benefit of doing this is you get a much simpler API for using WorkflowApplication. This API is included in the latest release of Microsoft.Activ.

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook