| Skip Navigation Links | |
| Exit Print View | |
 | man pages section 3: Basic Library Functions Oracle Solaris 11 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
| man pages section 3: Basic Library Functions Oracle Solaris 11 Information Library |
enable_extended_FILE_stdio(3C)
posix_spawnattr_getschedparam(3C)
posix_spawnattr_getschedpolicy(3C)
posix_spawnattr_getsigdefault(3C)
posix_spawnattr_getsigignore_np(3C)
posix_spawnattr_getsigmask(3C)
posix_spawnattr_setschedparam(3C)
posix_spawnattr_setschedpolicy(3C)
posix_spawnattr_setsigdefault(3C)
posix_spawnattr_setsigignore_np(3C)
posix_spawnattr_setsigmask(3C)
posix_spawn_file_actions_addclose(3C)
posix_spawn_file_actions_addclosefrom_np(3C)
posix_spawn_file_actions_adddup2(3C)
posix_spawn_file_actions_addopen(3C)
posix_spawn_file_actions_destroy(3C)
posix_spawn_file_actions_init(3C)
pthread_attr_getdetachstate(3C)
pthread_attr_getinheritsched(3C)
pthread_attr_getschedparam(3C)
pthread_attr_getschedpolicy(3C)
pthread_attr_setdetachstate(3C)
pthread_attr_setinheritsched(3C)
pthread_attr_setschedparam(3C)
pthread_attr_setschedpolicy(3C)
pthread_barrierattr_destroy(3C)
pthread_barrierattr_getpshared(3C)
pthread_barrierattr_setpshared(3C)
pthread_condattr_getpshared(3C)
pthread_condattr_setpshared(3C)
pthread_cond_reltimedwait_np(3C)
pthread_key_create_once_np(3C)
pthread_mutexattr_getprioceiling(3C)
pthread_mutexattr_getprotocol(3C)
pthread_mutexattr_getpshared(3C)
pthread_mutexattr_getrobust(3C)
pthread_mutexattr_setprioceiling(3C)
pthread_mutexattr_setprotocol(3C)
pthread_mutexattr_setpshared(3C)
pthread_mutexattr_setrobust(3C)
pthread_mutex_getprioceiling(3C)
pthread_mutex_reltimedlock_np(3C)
pthread_mutex_setprioceiling(3C)
pthread_rwlockattr_destroy(3C)
pthread_rwlockattr_getpshared(3C)
pthread_rwlockattr_setpshared(3C)
pthread_rwlock_reltimedrdlock_np(3C)
pthread_rwlock_reltimedwrlock_np(3C)
pthread_rwlock_timedrdlock(3C)
pthread_rwlock_timedwrlock(3C)
rctlblk_get_enforced_value(3C)
- condition variables
cc –mt [flag... ]file... [library... ]#include <thread.h> #include <synch.h>intcond_init(cond_t *cvp,inttype,void *arg);
intcond_wait(cond_t *cvp,mutex_t *mp);
intcond_timedwait(cond_t *cvp,mutex_t *mp,timestruc_t *abstime);
intcond_reltimedwait(cond_t *cvp,mutex_t *mp,timestruc_t *reltime);
intcond_signal(cond_t *cvp);
intcond_broadcast(cond_t *cvp);
intcond_destroy(cond_t *cvp);
Condition variables and mutexes should be global. Condition variables that are allocatedin writable memory can synchronize threads among processes if they are sharedby the cooperating processes (seemmap(2)) and are initialized for this purpose.
The scope of a condition variable is either intra-process or inter-process. Thisis dependent upon whether the argument is passed implicitly or explicitly tothe initialization of that condition variable. A condition variable does not needto be explicitly initialized. A condition variable is initialized with all zeros, bydefault, and its scope is set to within the calling process. Forinter-process synchronization, a condition variable must be initialized once, and only once,before use.
A condition variable must not be simultaneously initialized by multiple threads orre-initialized while in use by other threads.
Attributes of condition variables can be set to the default or customizedat initialization.
Thecond_init() function initializes the condition variable pointed to bycvp. Acondition variable can have several different types of behavior, specified bytype.No current type usesarg although a future type may specify additionalbehavior parameters witharg. Thetype argument c take one of thefollowing values:
The condition variable can synchronize threads only in this process. This is the default.
The condition variable can synchronize threads in this process and other processes. Only one process should initialize the condition variable. The object initialized with this attribute must be allocated in memory shared between processes, either in System V shared memory (seeshmop(2)) or in memory mapped to a file (seemmap(2)). It is illegal to initialize the object this way and to not allocate it in such shared memory.
Initializing condition variables can also be accomplished by allocating in zeroed memory,in which case, atype ofUSYNC_THREAD is assumed.
If default condition variable attributes are used, statically allocated condition variables canbe initialized by the macroDEFAULTCV.
Default condition variable initialization (intra-process):
cond_t cvp;cond_init(&cvp, NULL, NULL); /*initialize condition variable with default*/
or
cond_init(&cvp, USYNC_THREAD, NULL);
or
cond_t cond = DEFAULTCV;
Customized condition variable initialization (inter-process):
cond_init(&cvp, USYNC_PROCESS, NULL); /* initialize cv with inter-process scope */
The condition wait interface allows a thread to wait for a conditionand atomically release the associated mutex that it needs to hold tocheck the condition. The thread waits for another thread to make thecondition true and that thread's resulting call to signal and wakeup thewaiting thread.
Thecond_wait() function atomically releases the mutex pointed to bymp andcauses the calling thread to block on the condition variable pointed tobycvp. The blocked thread may be awakened bycond_signal(),cond_broadcast(), orwhen interrupted by delivery of a UNIX signal or afork().
Thecond_wait(),cond_timedwait(), andcond_reltimedwait() functions always return with the mutex lockedand owned by the calling thread even when returning an error, exceptwhen the mutex has theLOCK_ROBUST attribute and has been left irrecoverable bythe mutex's last owner. Thecond_wait(),cond_timedwait(), andcond_reltimedwait() functions return theappropriate error value if they fail to internally reacquire the mutex.
A condition signal allows a thread to unblock a single thread waitingon the condition variable, whereas a condition broadcast allows a thread tounblock all threads waiting on the condition variable.
Thecond_signal() function unblocks one thread that is blocked on the conditionvariable pointed to bycvp.
Thecond_broadcast() function unblocks all threads that are blocked on the conditionvariable pointed to bycvp.
If no threads are blocked on the condition variable, thencond_signal() andcond_broadcast() have no effect.
Thecond_signal() orcond_broadcast() functions can be called by a thread whetheror not it currently owns the mutex that threads callingcond_wait(),cond_timedwait(),orcond_reltimedwait() have associated with the condition variable during their waits. If, however,predictable scheduling behavior is required, then that mutex should be locked bythe thread prior to callingcond_signal() orcond_broadcast().
The condition destroy functions destroy any state, but not the space, associatedwith the condition variable.
Thecond_destroy() function destroys any state associated with the condition variable pointedto bycvp. The space for storing the condition variable is notfreed.
Upon successful completion, these functions return0. Otherwise, a non-zero value isreturned to indicate the error.
Thecond_timedwait() andcond_reltimedwait() functions will fail if:
The time specified byabstime orreltime has passed.
Thecond_wait(),cond_timedwait(), andcond_reltimedwait() functions will fail if:
Interrupted. The calling thread was awakened by the delivery of a UNIX signal.
If the mutex pointed to bymp is a robust mutex (initializedwith theLOCK_ROBUST attribute), thecond_wait(),cond_timedwait() andcond_reltimedwait() functions will, underthe specified conditions, return the following error values. For complete information, seethe description of themutex_lock() function on themutex_init(3C) manual page.
The mutex was protecting the state that has now been left irrecoverable. The mutex has not been acquired.
The last owner of the mutex died while holding the mutex, possibly leaving the state it was protecting inconsistent. The mutex is now owned by the caller.
These functions may fail if:
Thecond,attr,cvp,arg,abstime, ormutex argument points to an illegal address.
Invalid argument. Forcond_init(),type is not a recognized type. Forcond_timedwait(), the number of nanoseconds is greater than or equal to 1,000,000,000.
Example 1 Usecond_wait() in a loop to test some condition.
Thecond_wait() function is normally used in a loop testing some condition,as follows:
(void) mutex_lock(mp);while (cond == FALSE) { (void) cond_wait(cvp, mp);}(void) mutex_unlock(mp);Example 2 Usecond_timedwait() in a loop to test some condition.
Thecond_timedwait() function is normally used in a loop testing some condition. It uses an absolute timeout value as follows:
timestruc_t to;...(void) mutex_lock(mp);to.tv_sec = time(NULL) + TIMEOUT;to.tv_nsec = 0;while (cond == FALSE) { err = cond_timedwait(cvp, mp, &to); if (err == ETIME) { /* timeout, do something */ break; }}(void) mutex_unlock(mp);Example 3 Usecond_reltimedwait() in a loop to test some condition.
Thecond_reltimedwait() function is normally used in a loop testing in somecondition. It uses a relative timeout value as follows:
timestruc_t to;...(void) mutex_lock(mp);while (cond == FALSE) { to.tv_sec = TIMEOUT; to.tv_nsec = 0; err = cond_reltimedwait(cvp, mp, &to); if (err == ETIME) { /* timeout, do something */ break; }}(void) mutex_unlock(mp);Seeattributes(5) for descriptions of the following attributes:
|
fork(2),mmap(2),setitimer(2),shmop(2),mutex_init(3C),signal(3C),attributes(5),condition(5),mutex(5),standards(5)
If more than one thread is blocked on a condition variable, theorder in which threads are unblocked is determined by the scheduling policy.When each thread, unblocked as a result of acond_signal() orcond_broadcast(),returns from its call tocond_wait() orcond_timedwait() , the thread ownsthe mutex with which it calledcond_wait(),cond_timedwait(), orcond_reltimedwait(). The thread(s)that are unblocked compete for the mutex according to the scheduling policy andas if each had calledmutex_lock(3C).
Whencond_wait() returns the value of the condition is indeterminate and mustbe reevaluated.
Thecond_timedwait() andcond_reltimedwait() functions are similar tocond_wait(), except that thecalling thread will not wait for the condition to become true pastthe absolute time specified byabstime or the relative time specified byreltime.Note thatcond_timedwait() orcond_reltimedwait() might continue to block as it trysto reacquire the mutex pointed to bymp, which may be lockedby another thread. If eithercond_timedwait() orcond_reltimedwait() returns because of atimeout, it returns the error valueETIME.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.Legal Notices |   |