MUTEX

MUTual EXclusion

The term MUTEX stands for Mutual Exclusion which signifies that Tasks use this synchronization object to mutually exclude access from each other to resources.

A MUTEX is a lock object. Waiting on a MUTEX will block the Task until the MUTEX is ready to be acquired. When the waiting Task resumes it owns the MUTEX object and any other Task trying to use the MUTEX will now block on the call to the Wait function.

 

Protecting Code

Synchronization mechanisms used for Locking are commonly considered .to lock a code section so that two Tasks will not execute the same code block at the same time. A clear example to this is the lock object called Critical Section. This is very confusing to new developers and designers because lock objects do not really protect code section or any code for that matter.

 

Protecting Resource

As a matter of fact Lock synchronization objects protect resources not code sections. This is by application design and the designer should specify to developers a clear relation between resource and lock mechanism.

 

Unnamed

Most libraries have a version of lock objects that have no name. When the object is created with no name it is shared by using the object's Handle and thus can only be shared between Tasks that can share Handles, for example between threads of the same process or between processes spawned with Handles duplicated (Library specific).

 

Named

Lock objects created with a name can be shared between processes. All instances created using the same name relate to the same object and so all processes and threads can share the same Lock object. This allows processes to protect resources that can be shared between processes such as files, hardware resources and shared memory (this said ignoring the File System as an object management mechanism). The named Lock object is identified by its unique name which makes this name globally unique for the system just like a file path. This unique name is called an Atomic Name.

 

Thread termination

Lock objects are unique from other synchronization objects in their behavior and the way they are used. Synchronization objects in general are used to manage operations between Tasks. Most synchronization objects are signaled by one Task when another Task is waiting. Lock object are always expected to be unlocked by the same Task that performed successful lock. This means that a locked Lock object has an owner Task. In effect the library and operating system can know whether a Task exited or terminated without unlocking and perform the unlock in its behalf so that overall system stability is maintianed.

 

Critical Section

There are two types of Lock objects. The first is a system object that can be named and is usually implemented by Kernel and the other one is a local object that can only be used inside the process, usually implemented using atomic operations. a Critical Section is of the second type. Critical Section is a bad name indicating that it is used to protect a code section that is critical but in design we should match resources to lock objects.

 

 

 

More on Microsoft's MSDN

See more on Wikipedia