You copied the Doc URL to your clipboard.

Condition variables [ALPHA]

The C++ Thread Porting API provides functions for condition variables in the <arm-tpl.h> header file.

Note

This topic describes an [ALPHA] feature. See Support level definitions.

Types

struct __ARM_TPL_condvar_t {
    _Atomic uintptr_t data;
};

Functions

int __ARM_TPL_condvar_signal(__ARM_TPL_condvar_t* __cv);
int __ARM_TPL_condvar_broadcast(__ARM_TPL_condvar_t* __cv);
int __ARM_TPL_condvar_wait(__ARM_TPL_condvar_t* __cv, __ARM_TPL_mutex_t* __m);
int __ARM_TPL_condvar_timedwait(__ARM_TPL_condvar_t* __cv, __ARM_TPL_mutex_t* __m, __ARM_TPL_timespec_t* __ts); 
int __ARM_TPL_condvar_destroy(__ARM_TPL_condvar_t* __cv);

Usage

The C++ Thread Porting API uses the __ARM_TPL_condvar_t type to encapsulate a pointer to an underlying platform-specific condition variable type. The semantics of the functions are:

  • The functions __ARM_TPL_condvar_wait() and __ARM_TPL_condvar_timedwait() must operate on an initialize-on-first-use basis with respect to __cv->data. If the value __cv->data is zero, an implementation must first initialize __cv->data to point to a valid platform condition variable before carrying out the requested operation. This initialization must be thread-safe. For more information, see Thread-safe initialization of Mutexes and Condition variables [ALPHA].
  • The function __ARM_TPL_condvar_wait() must cause the calling thread (which is guaranteed to be the owner of the mutex __m) to block until the condition variable, __cv, is signaled by a different thread or the calling thread is interrupted. For the duration where the calling thread is blocked, the mutex __m must be unlocked. When this function returns, the unblocked thread must be the owner of the mutex, __m, regardless of the reason for unblocking. The reason for unblocking might be:
    • Condition variable is signaled.
    • The current thread is interrupted.
    This function must return zero to indicate success when a thread is unblocked as a result of the condition variable being signaled. This function must return a non-zero value to indicate any error conditions.
  • The function __ARM_TPL_condvar_timedwait() behaves similar to __ARM_TPL_condvar_wait(), except that it allows an explicit time limit to be specified for the blocking operation. If this function returns due to the timeout expiring, its return value shall be non-zero.
  • The functions __ARM_TPL_condvar_signal(), __ARM_TPL_condvar_broadcast() and __ARM_TPL_condvar_destroy() must return zero if the value __cv->data is zero. Otherwise, they should perform the requested operation on the platform condition variable pointed to by __cv->data and return zero if successful, or return non-zero if not successful.
  • The function __ARM_TPL_condvar_signal() must unblock at least one of the threads blocked on the condition variable __cv. The function __ARM_TPL_condvar_broadcast() must unblock all the threads blocked on the condition variable __cv. If more than one thread is unblocked as a result of a call to one of these functions, they must all contend for the respective mutexes with which they originally invoked __ARM_TPL_condvar_wait() or __ARM_TPL_condvar_timedwait() functions.
  • The function __ARM_TPL_condvar_destroy() must destroy the condition variable represented in __cv. It is guaranteed that an already destroyed __ARM_TPL_condvar_t object is not referenced through any API functions afterward. When successful, __ARM_TPL_condvar_destroy() must return zero, or a non-zero value if not successful.

Returns

These functions must return zero if successful, or return non-zero if not successful to indicate an error.

Was this page helpful? Yes No