[ новости /+++ | форум | теги | ]

NAME
     mutex - concepts relating to mutual exclusion locks

DESCRIPTION
     Mutual exclusion locks (mutexes)  prevent  multiple  threads
     from  simultaneously  executing  critical  sections  of code
     which access shared data (that is, mutexes are used to seri-
     alize 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.

     ____________________________________________________________
    |    FUNCTION           |               ACTION              |
    | mutex_init            |  Initialize a mutex.              |
    | mutex_destroy         |  Destroy a mutex.                 |
    | mutex_lock            |  Lock a mutex.                    |
    | mutex_trylock         |  Attempt to lock a mutex.         |
    | mutex_unlock          |  Unlock a mutex.                  |
    | pthread_mutex_init    |  Initialize a mutex.              |
    | pthread_mutex_destroy |  Destroy a mutex.                 |
    | pthread_mutex_lock    |  Lock a mutex.                    |
    | pthread_mutex_trylock |  Attempt to lock a mutex.         |
    | pthread_mutex_unlock  |  Unlock 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 allo-
     cated  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 appropri-
     ate 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 exclusive 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 performance and scalability of
     the application. Because too few mutexes can hinder the con-
     currency  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  attri-
     butes:

     ____________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    |_____________________________|_____________________________|
    | MT-Level                    | MT-Safe                     |
    |_____________________________|_____________________________|


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


NOTES
     In    the     current     implementation     of     threads,
     pthread_mutex_lock(),  pthread_mutex_unlock(),  mutex_lock()
     mutex_unlock(), pthread_mutex_trylock(), and mutex_trylock()
     do  not validate the mutex type. Therefore, an uninitialized
     mutex or a mutex with an invalid type does not  return  EIN-
     VAL.  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 mapplings to the same
     logical  synch  object. If you need to mmap() a synch object
     to different locations 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.

Партнёры:

Хостинг: