Warning: main(/www/www/htdocs/style/globals.php) [function.main]: failed to open stream: No such file or directory in /www/www/docs/6.4.1/neutrino/lib_ref/s/synccondvarwait.html on line 1

Warning: main() [function.include]: Failed opening '/www/www/htdocs/style/globals.php' for inclusion (include_path='.:/www/www/common:/www/www/php/lib/php') in /www/www/docs/6.4.1/neutrino/lib_ref/s/synccondvarwait.html on line 1

Warning: main(/www/www/htdocs/style/header.php) [function.main]: failed to open stream: No such file or directory in /www/www/docs/6.4.1/neutrino/lib_ref/s/synccondvarwait.html on line 8

Warning: main() [function.include]: Failed opening '/www/www/htdocs/style/header.php' for inclusion (include_path='.:/www/www/common:/www/www/php/lib/php') in /www/www/docs/6.4.1/neutrino/lib_ref/s/synccondvarwait.html on line 8

SyncCondvarWait(), SyncCondvarWait_r()

Block a thread on a synchronization object

Synopsis:

#include <sys/neutrino.h>

int SyncCondvarWait( sync_t * sync,
                     sync_t * mutex );

int SyncCondvarWait_r( sync_t * sync,
                       sync_t * mutex );

Arguments:

sync
A pointer to a sync_t for the synchronization object. You must have initialized this argument by calling SyncTypeCreate() or statically initialized it with the manifest PTHREAD_COND_INITIALIZER.
mutex
The mutex that's associated with the condition variable. You must lock this mutex by calling SyncMutexLock() (or the POSIX pthread_mutex_lock() cover routine). The kernel releases the mutex lock in the kernel when it blocks the thread on sync.

Library:

libc

Use the -l c option to qcc to link against this library. This library is usually included automatically.

Description:

The SyncCondvarWait() and SyncCondvarWait_r() kernel calls block the calling thread on the synchronization object, sync. If more than one thread is blocked on the object, they're queued in priority order.

These functions are similar, except in the way they indicate errors. See the Returns section for details.


Note: Instead of using these kernel calls directly, consider calling pthread_cond_timedwait() or pthread_cond_wait().

The blocked thread can be unblocked by any one of the following conditions:

Condition variable signalled
The condition variable was signaled by a call to SyncCondvarSignal(), that determined that this thread should be awakened.

Before returning from SyncCondvarWait(), mutex is reacquired. If mutex is locked, the thread enters into the STATE_MUTEX state waiting for mutex to be unlocked. At this point it's as though you had called SyncMutexLock(mutex).

Timeout
The wait was terminated by a timeout initiated by a previous call to TimerTimeout().

Before returning from SyncCondvarWait(), mutex is reacquired. If mutex is locked, the thread enters into the STATE_MUTEX state waiting for mutex to be unlocked. At this point it's as though you had called SyncMutexLock(mutex).

POSIX signal
The wait was terminated by an unmasked signal initiated by a call to SignalKill(). If a signal handler has been set up, the signal handler runs with mutex unlocked. On return from the signal handler, mutex is reacquired. If mutex is locked, the thread enters into the STATE_MUTEX state waiting for mutex to be unlocked. At this point, it's as though you had called SyncMutexLock(mutex).
Thread cancellation
The wait was terminated by a thread cancellation initiated by a call to ThreadCancel(). Before calling the cancellation handler, mutex is reacquired. If mutex is locked, the thread enters into the STATE_MUTEX state waiting for mutex to be unlocked. At this point, it's as though you had called SyncMutexLock(mutex).

In all cases, mutex is reacquired before the call returns. If the thread enters the STATE_MUTEX state, the rules governing SyncMutexLock() are in effect.

Condition variables are used to block a thread until a certain condition is satisfied. Spurious wakeups may occur due to timeouts, signals, and broadcast condition variable signals. Therefore, you should always reevaluate the condition, even on a successful return. The easiest way to do this is with a while loop. For example:

SyncMutexLock(&mutex);

while(some_condition) {
    SyncCondvarWait(&condvar, &mutex);
}

SyncMutexUnlock(&mutex);

Blocking states

STATE_CONDVAR
The calling thread blocks waiting for the condition variable to be signaled.
STATE_MUTEX
The thread was unblocked from the STATE_CONDVAR state and while trying to reacquire the controlling mutex, found the mutex was locked by another thread.

Returns:

The only difference between these functions is the way they indicate errors:

SyncCondvarWait()
If an error occurs, the function returns -1 and sets errno. Any other value returned indicates success.
SyncCondvarWait_r()
Returns EOK on success. This function does NOT set errno. If an error occurs, the function returns any value in the Errors section.

Errors:

EAGAIN
On the first use of a statically initialized sync, all kernel synchronization objects were in use.
EFAULT
A fault occurred when the kernel tried to access sync or mutex.
EINVAL
The synchronization ID specified in sync doesn't exist.
ETIMEDOUT
A kernel timeout unblocked the call. See TimerTimeout().

Classification:

QNX Neutrino

Safety:
Cancellation point Yes
Interrupt handler No
Signal handler Yes
Thread Yes

See also:

pthread_cond_broadcast(), pthread_cond_signal(), pthread_cond_timedwait(), pthread_cond_wait(), pthread_mutex_lock(), SignalKill(), SyncCondvarSignal(), SyncMutexLock(), SyncTypeCreate(), ThreadCancel(), TimerTimeout()


Warning: main(/www/www/htdocs/style/footer.php) [function.main]: failed to open stream: No such file or directory in /www/www/docs/6.4.1/neutrino/lib_ref/s/synccondvarwait.html on line 308

Warning: main() [function.include]: Failed opening '/www/www/htdocs/style/footer.php' for inclusion (include_path='.:/www/www/common:/www/www/php/lib/php') in /www/www/docs/6.4.1/neutrino/lib_ref/s/synccondvarwait.html on line 308