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

NAME
     condition - concepts related to condition variables

DESCRIPTION
     Occasionally, a thread running within a mutex needs to  wait
     for  an  event,   in  which case it blocks or sleeps. When a
     thread is waiting for  another  thread  to  communicate  its
     disposition,  it  uses  a  condition variable in conjunction
     with a mutex. Although a mutex is exclusive and the code  it
     protects  is  sharable (at certain moments), condition vari-
     ables enable the synchronization of  differing  events  that
     share  a  mutex, but not necessarily data. Several condition
     variables may be used by threads to signal each other   when
     a  task  is  complete,  which  then  allows the next waiting
     thread to take  ownership of the mutex.

     A condition variable enables threads to atomically block and
     test  the condition under the protection of a  mutual exclu-
     sion lock (mutex) until the condition is satisfied.  If  the
     condition  is false, a thread blocks on a condition variable
     and atomically releases the mutex that is  waiting  for  the
     condition  to  change.  If another thread changes the condi-
     tion, it may wake up waiting threads by signaling the  asso-
     ciated condition variable. The waiting threads, upon awaken-
     ing, reacquire the mutex and re-evaluate the condition.

  Initialize
     Condition variables and mutexes should be global.  Condition
     variables  that  are  allocated  in writable memory can syn-
     chronize threads among processes if they are shared  by  the
     cooperating  processes (see mmap(2)) and are initialized for
     this purpose.

     The scope of a condition variable is either intra-process or
     inter-process.  This  is dependent upon whether the argument
     is passed implicitly or explicitly to the initialization  of
     that  condition variable. A condition variable does not need
     to be explicitly initialized. A condition variable  is  ini-
     tialized  with  all  zeros, by default, and its scope is set
     to within the calling process. For inter-process  synchroni-
     zation,  a  condition variable must be initialized once, and
     only once, before use.

     A condition variable must not be simultaneously  initialized
     by  multiple threads or re-initialized while in use by other
     threads.

     Condition variables attributes may be set to the default  or
     customized  at initialization.  POSIX threads even allow the
     default values to be customized. Establishing  these  attri-
     butes varies depending upon whether POSIX or Solaris threads
     are used. Similar to  the  distinctions  between  POSIX  and
     Solaris thread creation, POSIX condition variables implement
     the default, intra-process, unless an  attribute  object  is
     modified  for  inter-process  prior to the initialization of
     the condition variable.  Solaris  condition  variables  also
     implement  as the default,  intra-process; however, they set
     this attribute according to the argument,  type,  passed  to
     their initialization function.

  Condition Wait
     The condition wait interface allows a thread to wait  for  a
     condition  and  atomically release the associated mutex that
     it needs to hold to check the condition.  The  thread  waits
     for  another  thread  to  make  the  condition true and that
     thread's resulting call to signal  and  wakeup  the  waiting
     thread.

  Condition Signaling
     A condition signal allows  a  thread  to  unblock  the  next
     thread  waiting on the condition variable, whereas, a condi-
     tion broadcast allows a thread to unblock all threads  wait-
     ing on the  condition variable.

  Destroy
     The condition destroy functions destroy any state,  but  not
     the space, associated with the condition variable.

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

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


SEE ALSO
     fork(2), mmap(2), setitimer(2),  shmop(2),  cond_init(3THR),
     cond_wait(3THR),   cond_timedwait(3THR),  cond_signal(3THR),
     cond_broadcast(3THR),    cond_destroy(3THR),    mutex(3THR),
     pthread_condattr_init(3THR),        pthread_cond_init(3THR),
     pthread_cond_wait(3THR),       pthread_cond_timedwait(3THR),
     pthread_cond_signal(3THR),     pthread_cond_broadcast(3THR),
     pthread_cond_destroy(3THR), signal(3C), attributes(5), stan-
     dards(5)

NOTES
     If more than one thread is blocked on a condition  variable,
     the  order  in  which threads are unblocked is determined by
     the scheduling policy.

     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.

Партнёры:

Хостинг: