12 <concept xml:lang="en" id="GUID-FA120B3F-4EC4-5A0A-8A36-D5CD032CF1B0"><title>Using Mutexes</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>Mutexes provide serialised access to shared resources. They are Kernel objects and, as such, are managed by the Kernel.</p> <p>A mutex can be used by threads across any number of processes. If a resource is only shared between the threads within the same process, it can be more efficient to use a critical section.</p> <p>Access to a mutex is through an RMutex handle.</p> <p>Mutexes are similar to semaphores in that they have a <codeph>TInt</codeph> count value that is incremented by calling the <codeph>Signal()</codeph> member function of the mutex handle and decremented by calling the <codeph>Wait()</codeph> member function of the mutex handle. A mutex with a negative value implies that a thread must wait for access to the shared resource.</p> <p>Unlike a semaphore, the count value of a mutex is always set to one when it is constructed.</p> <p>The creator of a shared resource uses the <codeph>CreateLocal()</codeph> or <codeph>CreateGlobal()</codeph> member functions of <codeph>RMutex</codeph> to create a mutex and to open the handle to it. Any thread wishing to access the resource first calls <codeph>Wait()</codeph>; that thread then calls <codeph>Signal()</codeph> after completing its access.</p> <p>The first thread to call <codeph>Wait()</codeph> returns immediately, and is free to continue execution, but any other threads that call <codeph>Wait()</codeph> will wait in a queue maintained by the mutex. Waiting threads are released on a first-in first-out basis when the thread currently accessing the resource calls <codeph>Signal()</codeph>.</p> <p>The nature of the shared resources should be such that any access completes in a relatively short time so that threads do not wait for extensive periods on the mutex.</p> <p>In many cases, it may be better to use servers to serialize access to a shared resource (for example, the window server) rather than use a mutex. </p> </conbody></concept>

    12 <concept id="GUID-FA120B3F-4EC4-5A0A-8A36-D5CD032CF1B0" xml:lang="en"><title>Using

    13 Mutexes</title><shortdesc>This document describes how to use mutexes.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    14 <p>Mutexes provide serialised access to shared resources. They are Kernel

    15 objects and, as such, are managed by the Kernel.</p>

    16 <p>A mutex can be used by threads across any number of processes. If a resource

    17 is only shared between the threads within the same process, it can be more

    18 efficient to use a critical section.</p>

    19 <p>Access to a mutex is through an RMutex handle.</p>

    20 <p>Mutexes are similar to semaphores in that they have a <codeph>TInt</codeph> count

    21 value that is incremented by calling the <codeph>Signal()</codeph> member

    22 function of the mutex handle and decremented by calling the <codeph>Wait()</codeph> member

    23 function of the mutex handle. A mutex with a negative value implies that a

    24 thread must wait for access to the shared resource.</p>

    25 <p>Unlike a semaphore, the count value of a mutex is always set to one when

    26 it is constructed.</p>

    27 <p>The creator of a shared resource uses the <codeph>CreateLocal()</codeph> or <codeph>CreateGlobal()</codeph> member

    28 functions of <codeph>RMutex</codeph> to create a mutex and to open the handle

    29 to it. Any thread wishing to access the resource first calls <codeph>Wait()</codeph>;

    30 that thread then calls <codeph>Signal()</codeph> after completing its access.</p>

    31 <p>The first thread to call <codeph>Wait()</codeph> returns immediately, and

    32 is free to continue execution, but any other threads that call <codeph>Wait()</codeph> will

    33 wait in a queue maintained by the mutex. Waiting threads are released on a

    34 first-in first-out basis when the thread currently accessing the resource

    35 calls <codeph>Signal()</codeph>.</p>

    36 <p>The nature of the shared resources should be such that any access completes

    37 in a relatively short time so that threads do not wait for extensive periods

    38 on the mutex.</p>

    39 <p>In many cases, it may be better to use servers to serialize access to a

    40 shared resource (for example, the window server) rather than use a mutex. </p>

    41 </conbody></concept>