unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

mutex(5)              Standards, Environments, and Macros             mutex(5)



NAME
       mutex - concepts relating to mutual exclusion locks

DESCRIPTION
       Mutual exclusion locks (mutexes) prevent multiple threads from simulta-
       neously executing critical sections of code which  access  shared  data
       (that  is, mutexes are used to serialize the execution of threads). All
       mutexes must be global. A successful call to acquire a mutex will cause
       another  thread  that  is  also  trying to lock the same mutex to block
       until the owner thread unlocks the mutex.

       Mutexes can synchronize threads within the same  process  or  in  other
       processes. Mutexes can be used to synchronize threads between processes
       if the mutexes are allocated in writable memory and  shared  among  the
       cooperating processes (see mmap(2)), and have been initialized for this
       task.

       The following table lists mutex functions and the actions they perform.

       tab() box; cw(2.194444i)| cw(3.305556i)  lw(2.194444i)|  lw(3.305556i).
       FUNCTION         ACTION mutex_initInitialize a mutex.  mutex_destroyDe-
       stroy a mutex.  mutex_lockLock a mutex.  mutex_trylockAttempt to lock a
       mutex.   mutex_unlockUnlock  a  mutex.   pthread_mutex_initInitialize a
       mutex.  pthread_mutex_destroyDestroy a mutex.  pthread_mutex_lockLock a
       mutex.      pthread_mutex_trylockAttempt     to     lock    a    mutex.
       pthread_mutex_unlockUnlock a mutex.


   Initialization
       Mutexes are either intra-process or inter-process, depending  upon  the
       argument  passed implicitly or explicitly to the initialization of that
       mutex.  A statically allocated mutex does not  need  to  be  explicitly
       initialized;  by  default,  a statically allocated mutex is initialized
       with all zeros and its scope is set to be within the calling process.

       For inter-process synchronization, a mutex needs  to  be  allocated  in
       memory  shared  between  these  processes.  Since the memory for such a
       mutex must be allocated dynamically, the mutex needs to  be  explicitly
       initialized with the appropriate attribute that indicates inter-process
       use.

   Locking and Unlocking
       A critical section of code is enclosed by a call to lock the mutex  and
       the  call to unlock the mutex to protect it from simultaneous access by
       multiple threads. Only one thread at a time may possess mutually exclu-
       sive  access  to  the  critical section of code that is enclosed by the
       mutex-locking call and the mutex-unlocking call,  whether  the  mutex's
       scope  is  intra-process or inter-process. A thread calling to lock the
       mutex either gets exclusive
        access to the code starting from the successful locking until its call
       to  unlock  the  mutex,  or it waits until the mutex is unlocked by the
       thread that locked it.

       Mutexes have ownership, unlike semaphores. Only the thread that  locked
       a mutex, (that is, the owner of the mutex), should unlock it.

       If a thread waiting for a mutex receives a signal, upon return from the
       signal handler, the thread resumes waiting for the mutex  as  if  there
       was no interrupt.

   Caveats
       Mutexes are almost like data - they can be embedded in data structures,
        files, dynamic or static memory, and so forth. Hence, they are easy to
       introduce into a program. However, too many mutexes can degrade perfor-
       mance  and  scalability of the application. Because too few mutexes can
       hinder the concurrency of the application, they  should  be  introduced
       with care. Also, incorrect usage (such as recursive calls, or violation
       of locking order, and so forth) can lead to deadlocks, or  worse,  data
       inconsistencies.

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:


       tab()     allbox;     cw(2.750000i)|    cw(2.750000i)    lw(2.750000i)|
       lw(2.750000i).  ATTRIBUTE TYPEATTRIBUTE VALUE MT-LevelMT-Safe


SEE ALSO
       mmap(2), shmop(2), mutex_destroy(3C),  mutex_init(3C),  mutex_lock(3C),
       mutex_trylock(3C),         mutex_unlock(3C),        pthread_create(3C),
       pthread_mutex_destroy(3C),                      pthread_mutex_init(3C),
       pthread_mutex_lock(3C),                      pthread_mutex_trylock(3C),
       pthread_mutex_unlock(3C),  pthread_mutexattr_init(3C),   attributes(5),
       standards(5)

NOTES
       In   the   current  implementation  of  threads,  pthread_mutex_lock(),
       pthread_mutex_unlock(), mutex_lock() mutex_unlock(), pthread_mutex_try-
       lock(),  and mutex_trylock() do not validate the mutex type. Therefore,
       an uninitialized mutex or a mutex with an invalid type does not  return
       EINVAL.  Interfaces  for  mutexes with an invalid type have unspecified
       behavior.

       By default, if multiple threads are waiting for a mutex, the  order  of
       acquisition is undefined.

       USYNC_THREAD  does  not  support  multiple mappings to the same logical
       synch object. If you need to mmap() a synch object to  different  loca-
       tions  within  the  same address space, then the synch object should be
       initialized  as  a  shared  object  USYNC_PROCESS  for   Solaris,   and
       PTHREAD_PROCESS_PRIVATE for POSIX.



SunOS 5.10                        20 Jul 1998                         mutex(5)