Overview | Group | Tree | Graph | Index | Concepts |
The class IloSemaphore
provides synchronization primitives adapted to
Concert Technology. This class supports inter-thread communication in multithread
applications. An instance of this class, a semaphore, is a counter; its value is
always positive. This counter can be incremented or decremented. You can always
increment a semaphore, and incrementing is a non-blocking operation. However, the
value of the counter cannot be negative, so any thread that attempts to decrement a
semaphore whose counter is already equal to 0 (zero) is blocked until another thread
increments the semaphore.
See ILOUSEMT
for details about the compilation
macro to use with instances of this class.
System Class
IloSemaphore
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
in a Concert Technology environment are managed by an instance of IloEnv
.
However, system classes, such as IloSemaphore
, differ from that
pattern. IloSemaphore
is an ordinary C++ class. Its instances are
allocated on the C++ heap.
Instances of IloSemaphore
are not automatically de-allocated by a call
to the member function IloEnv::end
. You must explicitly
destroy instances of IloSemaphore
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 IloSemaphore
in a Concert Technology environment because the
destructor for that instance of IloSemaphore
will never be called
automatically by IloEnv::end
when it cleans up other
Concert Technology objects in that Concert Technology environment.
For example, it is not a good idea to make an instance of IloSemaphore
part of a conventional Concert Technology model allocated in a Concert Technology
environment because that instance will not automatically be de-allocated from the
Concert Technology environment along with the other Concert Technology objects.
De-allocating Instances of IloSemaphore
Instances of IloSemaphore
differ from the usual Concert Technology
objects because they are not allocated in a Concert Technology environment, and their
de-allocation is not managed automatically for you by
IloEnv::end
. Instead, you must explicitly destroy
instances of IloSemaphore
by calling the delete operator when your
application no longer needs those objects.
See Also:
IloBarrier, IloCondition, ILOUSEMT
Constructor and Destructor Summary | |
---|---|
public | IloSemaphore(int) |
public | ~IloSemaphore() |
Method Summary | |
---|---|
public void | post() |
public int | tryWait() |
public void | wait() |
Constructor and Destructor Detail |
---|
This constructor creates an instance of IloSemaphore
, initializes it
to value
, and allocates it on the C++ heap (not in a Concert Technology
environment). If you do not pass a value
parameter, the constructor
initializes the semaphore at 0 (zero).
The delete operator calls this destructor to de-allocate an instance of
IloSemaphore
. This destructor is called automatically by the runtime
system. The destructor de-allocates operating system-specific data structures.
Method Detail |
---|
This member function increments the invoking semaphore by 1 (one). If there are threads blocked at this semaphore, then this member function wakes one of them.
This member function attempts to decrement the invoking semaphore by 1 (one). If this decrement leaves the counter positive, then the call succeeds and returns 1 (one). If the decrement would make the counter strictly negative, then the decrement does not occur, the call fails, and the member function returns 0 (zero).
This member function decrements the invoking semaphore by 1 (one).
If this decrement would make the semaphore strictly negative, then this member function blocks the calling thread. The thread wakes up when the member function can safely decrement the semaphore without causing the counter to become negative (for example, if another entity increments the semaphore). If this member function cannot decrement the invoking semaphore, then it leads to deadlock.