Class IloCondition

The class IloCondition provides synchronization primitives adapted to Concert Technology for use in a parallel application.

See ILOUSEMT for details about the compilation macro to use with instances of this class.

An instance of the class IloCondition allows several threads to synchronize on a specific event. In this context, inter-thread communication takes place through signals. A thread expecting a condition of the computation state (say, conditionC) to be true before it executes a treatmentT can wait until the condition is true. When computation reaches a state where conditionC holds, then another thread can signal this fact by notifying a single waiting thread or by broadcasting to all the waiting threads that conditionC has now been met.

The conventional template for waiting on conditionC looks like this:

 mutex.lock();
 while (conditionC does not hold)
        condition.wait(&mutex);
 doTreatmentT();
 mutex.unlock();
 

That template has the following properties:

• The whole fragment is a critical section so that the evaluation of conditionC is protected. (Indeed, it would be unsafe to evaluate conditionC while at the same time another thread modifies the computation state and affects the truth value of conditionC.) The pair of member functions IloFastMutex::lock and IloFastMutex::unlock delimit the critical section.
• When a thread enters the wait call, the mutex is automatically unlocked by the system.
• The loop that repeatedly checks conditionC is essential to the correctness of the code fragment. It protects against the following possibility: between the time that a thread modifies the computation state (so that conditionC holds) and notifies a waiting thread and the moment the waiting thread wakes up, the computation state might have been changed by another thread, and conditionC might very well be false.
• Upon returning from the wait call, the mutex is locked. The operation of waking up and locking the mutex is atomic. In other words, nothing can happen between the waking and the locking.

System Class

IloCondition is a system class.

Most Concert Technology classes are actually handle classes whose instances point to objects of a corresponding implementation class. For example, instances of the Concert Technology class IloNumVar are handles pointing to instances of the implementation class IloNumVarI. Their allocation and de-allocation on the Concert Technology heap are managed by an instance of IloEnv.

However, system classes, such as IloCondition, differ from that Concert Technology pattern. IloCondition is an ordinary C++ class. Its instances are allocated on the C++ heap.

Instances of IloCondition are not automatically de-allocated by a call to IloEnv::end. You must explicitly destroy instances of IloCondition by means of a call to the delete operator (which calls the appropriate destructor) when your application no longer needs instances of this class.

Furthermore, you should not allocate—neither directly nor indirectly—any instance of IloCondition on the Concert Technology heap because the destructor for that instance of IloCondition will never be called automatically by IloEnv::end when it cleans up other Concert Technology objects on the Concert Technology heap.

For example, it is not a good idea to make an instance of IloCondition part of a conventional Concert Technology model allocated on the Concert Technology heap because that instance will not automatically be de-allocated from the Concert Technology heap along with the other Concert Technology objects.

De-allocating Instances of IloCondition

Instances of IloCondition differ from the usual Concert Technology objects because they are not allocated on the Concert Technology heap, and their de-allocation is not managed automatically for you by IloEnv::end. Instead, you must explicitly destroy instances of IloCondition by calling the delete operator when your application no longer needs those objects.

This constructor creates an instance of IloCondition and allocates it on the C++ heap (not in a Concert Technology environment). The instance contains data structures specific to an operating system.

The delete operator calls this destructor to de-allocate an instance of IloCondition. This destructor is called automatically by the runtime system. The destructor de-allocates data structures (specific to an operating system) of the invoking condition.

This member function wakes all threads currently waiting on the invoking condition. If there are no threads waiting, this member function does nothing.

This member function wakes one of the threads currently waiting on the invoking condition.

This member function first puts the calling thread to sleep while it unlocks the mutex m. Then, when either of the member functions broadcast or notify wakes up that thread, this member function acquires the lock on m and returns.