Class IlcSchedule

An instance of the class IlcSchedule is an object which represents a schedule. Although most applications will use only one schedule, it is possible to use multiple schedules, for example, to simulate distributed scheduling. A schedule manages resources that are required or provided by activities.

A schedule is associated with a time interval defined by timeMin, the origin of the schedule, and timeMax, the horizon of the schedule. By convention, the time interval is considered closed on the left and open on the right, denoted like this: [timeMin, timeMax). This convention makes it possible to define time-varying parameters (such as the number of resources available) at any given time. In the Scheduler Engine library, integers are used to represent time so the value assumed by a parameter at a given time is the value assumed over the entire interval[time, (time + 1)). The time origin and the time horizon are used by default to initialize timetables of resources as well as earliest start times and latest end times of activities.

Printing or Displaying a Schedule

The printed representation of an instance of the class IlcSchedule consists of two parts: its name followed by the values of its two constructor arguments, timeMin and timeMax. These two values are enclosed in brackets and separated by two dots, like this: [0..10].

If the Solver trace is active and the schedule has not been named, the string "IlcSchedule" followed by the address of the implementation object precedes the values of the two constructor arguments, timeMin and timeMax, enclosed in brackets.

Inverse Links

An instance of the class IlcSchedule may be a data member of another "external" object. In such a case, it may be useful to find the external object from the instance of IlcSchedule. The member functions getObject and setObject are provided to manage such an inverse link.

Handles and Implementation Classes

Like Solver, Scheduler Engine implements most of its entities by means of handle classes and implementation classes, where an object of the handle class contains a pointer (the handle pointer) to an instance of the corresponding implementation class (the implementation object). These two levels allow Scheduler to do most of the memory management for you. For more details about handle and implementation classes, see that topic in the Solver Reference Manual. Normally, as a Scheduler Engine user, you will exploit handles.

There are two cases in which you should use the implementation class:

1. When you define a transition time object and choose not to use the macro IlcTransitionTime. See IlcTransitionTimeObjectI for an example of deriving a new transition time object.
2. When you define a transition cost object and choose not to use the macro IlcTransitionCost. See IlcTransitionCostObjectI for an example of deriving a new transition cost object.

For more information, see Durability, and the Solver Reference Manual.

After creation of all its durable resources, a durable schedule may be closed by calling this member function. After closing, no further durable resources can be created on the invoking schedule. Closing a durable schedule is not reversible.

Calling this member function is mandatory only in multi-threaded applications and must occur before using any of the durable resources constructed on the invoking durable schedule.

This member function has relevance for durable schedules only.

This member function returns the number of activities managed by the invoking schedule.

This member function returns the number of resources managed by the invoking schedule.

This member function returns the precedence graph constraint associated with the invoking schedule.

This member function returns an instance of IloSolver associated with the invoking object.

This member function returns a pointer to the implementation object of the solver where the invoking object was extracted.

This member function returns the time horizon of the invoking schedule. This value is defined in the IloSchedulerEnv associated with the model extracted by the IlcScheduler object.

This member function returns the time origin of the invoking schedule. This value is defined in the IloSchedulerEnv associated with the model extracted by the IlcScheduler object.

This member function returns IlcTrue if the invoking schedule is associated with a precedence graph constraint.

This member function returns IlcTrue if the invoking schedule has been closed. Otherwise it returns IlcFalse.

This member function returns IlcTrue if the invoking schedule has been declared as durable. Otherwise it returns IlcFalse.

These member functions allow the invoking schedule object to lock one or several durable resources. The resources passed as arguments must be durable resources constructed on the same durable schedule.

Before using one or several durable resources to define a scheduling problem, the schedule associated with the problem must lock those durable resources.

After calling lock, the resources are considered to be locked by the invoking schedule. The invoking schedule is called the computation schedule and its solver the computation solver.

Trying to lock resources already locked by another schedule in the same thread will raise an error. Trying to lock resources already locked by other schedules in different threads may cause the current thread to be blocked while waiting for all arguments to be unlocked by other threads.

Note that in multi-threaded applications, the use of lock in loops like:

    for(IlcInt i = 0; i < SIZE; i++)
       compSchedule.lock(1, resourceArray[i]);

may result in deadlocks. The correct use should be:

compSchedule.lock(SIZE, resourceArray);

Trying to lock a resource already locked by the same schedule has no effect.

The method lock is reversible under backtracking and the associated reversible action is IlcSchedule::unlock with the same arguments.

After locking by compSchedule, the following equalities are true for a locked resource:

 resource.getSchedule() == compSchedule;
 resource.getSolver() == compSchedule.getSolver();

A resource is locked if and only if the following test succeeds:

resource.getDurableSchedule() != resource.getSchedule()

A resource that has just been locked does not have any resource constraints or global constraints, except global constraints created on the allocation solver. If global constraints were already added on the durable schedule, they will be added automatically to the computation schedule.

Locked resources can be used for creating and adding resource constraints on the solver of the computation schedule.

This member function creates and returns the precedence graph constraint associated with the invoking schedule. The constraint must be posted in order to be taken into account.

This operator returns IlcTrue if and only if schedule does not refer to the same implementation object as the invoking schedule.

This operator returns IlcTrue if and only if schedule refers to the same implementation object as the invoking schedule.

This member function declares the invoking schedule as durable. This member function must be used outside the search. This solver is called the allocation solver.

Durable schedules should be used only to create resources and global constraints (timetable, break, and disjunctive constraints) on these resources. Such resources are called durable resources. Durable resources can be grouped into alternatives (IlcAltResSet) on the durable schedule.

Activities cannot be created on a durable schedule and resource constraints cannot be added to the allocation solver. A schedule already containing some resources and/or activities cannot be set as durable.

Setting a schedule as durable is not reversible.

These member functions allow the invoking schedule object to unlock one or several durable resources. The resources passed as arguments must be durable resources constructed on the same durable schedule. Unlocking may be performed during search.

All constraints (resource and global) that are using the unlocked resources become "inhibited," meaning that no further propagation will occur through them. Unlocked resources keep the timetable information that was computed before they were unlocked.

For any unlocked resource the following equalities are true:

 resource.getSchedule() == resource.getDurableSchedule();
 resource.getSolver() == resource.getDurableSchedule().getSolver();
 

Unlocked resources are in a state allowing them to be locked. Further computation performed on the schedule does not affect the unlocked resource, except backtracking. Backtracking a decision that modified the timetable of a resource will undo the modification, even if the resource has been unlocked.

Do not call unlock during propagation. Trying to unlock a resource which is not locked by the invoking schedule has no effect.

Note that unlock is not reversible, that is, an unlocked resource will not be locked again under backtracking and inhibited constraints remain inhibited.

This member function associates the schedule demon d with changes to the set of activities that are direct predecessors of an activity of the invoking schedule. When the set of activities that are direct predecessors of an activity changes because some new direct predecessors have appeared, the demon d is executed on the activity whose set of direct predecessors has changed.

This member function has no effect until a precedence graph constraint has been created on the schedule.

This member function associates the schedule demon d with changes to the set of activities that are direct successors of an activity of the invoking schedule. When the set of activities that are direct successors of an activity changes because some new direct successors have appeared, the demon d is executed on the activity whose set of direct successors has changed.

This member function has no effect until a precedence graph constraint has been created on the schedule.

This member function associates the schedule demon d with changes to the set of activities that are predecessors of an activity of the invoking schedule. When the set of activities that are predecessors of an activity changes because some new predecessors have appeared, the demon d is executed on the activity whose set of predecessors has changed.

This member function has no effect until a precedence graph constraint has been created on the schedule.

This member function associates the schedule demon d with changes to the set of activities that are successors of an activity of the invoking schedule. When the set of activities that are successors of an activity changes because some new successors have appeared, the demon d is executed on the activity whose set of successors has changed.

This member function has no effect until a precedence graph constraint has been created on the schedule.