Broadcast to a condition variable

This unblocks all threads which are currently blocked on the condition variable. If there are no threads currently waiting this call does nothing.

It is not required that any mutex is held when calling this function but it is recommended that the mutex associated with the condition variable is held since otherwise a race condition can result from the condition variable being signalled just after the waiting thread testing the condition and before it calls Wait() .

Creates a global condition variable and opens this handle to it.

If the specified name is a non-empty string the kernel side object representing the condition variable is given the specified name and is therefore global. It may subsequently be opened by name using the RCondVar::OpenGlobal function. If the specified name is empty the kernel side object representing the condition variable is unnamed and so cannot be opened by name. It can however be passed to another process as a process parameter or via IPC.

If the specified name is non-empty it must consist entirely of printable ASCII characters (codes 0x20 to 0x7e inclusive) and may not contain : * or ?.

By default, any thread in the process can use this instance of RCondVar to access the condition variable. However, specifying EOwnerThread as the parameter to this function means that only the creating thread can use this instance of RCondVar to access the condition variable; any other thread in this process that wants to access the condition variable must duplicate this handle.

RCondVar::OpenGlobal() RHandleBase::Duplicate() RProcess::SetParameter(TInt, RHandleBase) TIpcArgs::Set(TInt, RHandleBase) RMessagePtr2::Complete(RHandleBase)

Creates a condition variable and opens this handle to it.

The kernel side object representing the condition variable is unnamed and so the condition variable cannot be found by name and hence it is local to the current process.

By default, any thread in the process can use this instance of RCondVar to access the condition variable. However, specifying EOwnerThread as the parameter to this function means that only the creating thread can use this instance of RCondVar to access the condition variable; any other thread in this process that wants to access the condition variable must duplicate this handle.

RHandleBase::Duplicate()

Opens a handle to a condition variable using a handle number sent by a client to a server.

This function is called by the server.

Opens a handle to a condition variable using a handle number passed as an environment data item to the child process during the creation of that child process.

Note that this function can only be called successfully once.

RProcess::SetParameter()

Opens a handle to a global condition variable.

Global condition variables are identified by name.

By default, any thread in the process can use this instance of RCondVar to access the condition variable. However, specifying EOwnerThread as the parameter to this function means that only the creating thread can use this instance of RCondVar to access the condition variable; any other thread in this process that wants to access the condition variable must either duplicate this handle or use OpenGlobal again.

RHandleBase::Duplicate()

Signal a condition variable

This unblocks a single thread which is currently blocked on the condition variable. The highest priority waiting thread which is not explicitly suspended will be the one unblocked. If there are no threads currently waiting this call does nothing.

It is not required that any mutex is held when calling this function but it is recommended that the mutex associated with the condition variable is held since otherwise a race condition can result from the condition variable being signalled just after the waiting thread testing the condition and before it calls Wait() .

Wait on a condition variable with timeout

This is the same as RCondVar::Wait(RMutex) except that there is a time limit on how long the current thread will block while waiting for the condition variable.

Wait on a condition variable

This call releases the specified mutex then atomically blocks the current thread on this condition variable. The atomicity here is with respect to the condition variable and mutex concerned. Specifically if the condition variable is signalled at any time after the mutex is released then this thread will be awakened. Once the thread has awakened it will reacquire the specified mutex before this call returns (except in the case where the condition variable has been deleted).

The usage pattern for this is as follows:

         mutex.Wait();
	while(!CONDITION)
		condvar.Wait(mutex);
	STATEMENTS;
	mutex.Signal();
        

where CONDITION is an arbitrary condition involving any number of user-side variables whose integrity is protected by the mutex.

It is necessary to loop while testing the condition because there is **no** guarantee that the condition has been satisfied when the condition variable is signalled. Different threads may be waiting on different conditions or the condition may have already been absorbed by another thread. All that can be said is that the thread will awaken whenever something happens which **might** affect the condition.

It needs to be stressed that if:

         condvar.Wait(mutex);
        

completes, it does not necessarily mean that the condition is yet satisfied, hence the necessity for the loop.