FAULT TOLERANT SCHEDULING

The approach to fault tolerant scheduling uses the additional ghost copies of
tasks, which are embedded into the schedule and activated whenever a
processor carrying one of their corresponding primary or previously activated
ghost copies fail. These ghost copies need not be identical to the primary copies,
they may be alternative versions that take less time to run and provide results of
poorer but still acceptable quality than the primaries.

We will assume a set of periodic tasks critical tasks. Multiple copies of each
version of a task are assumed to be executed in parallel. When a processor fails
there are two types of tasks that are affected by that failure. The first type is the
task that is running at the time of failure, and the second type comprises those
that were to have been run by that processor in the future. The use of forward
error recovery is assumed to be sufficient to compensate for the loss of first type
of tasks. The fault tolerant scheduling algorithm is meant to compensate the
second type by finding substitute processors to run those copies.

We assume the existence of a non fault-tolerant algo for allocation and

scheduling. This algorithm is called as a sub routine by the fault tolerant
scheduling procedure. We assume that the allocation/scheduling procedure
consists of an assignment part πa and a scheduling part πs.

Suppose the system is meant to run nc(i) copies of each version of task Ti, and is
supposed to tolerate up to nsust processor failures. The fault tolerant schedule
must ensure that, after some time for reacting to failure(s), the system can still
execute nc(i) copies of each version of task I, despite the failure up to nsust
processors. The failures may execute in any order.

The output of our fault tolerant scheduling algorithm will be a ghost schedule,
plus one or more primary schedules for each processor. If one or more ghost
schedule is to be run , the processor runs the ghost at the times specified by the
ghost schedule and shifts the primary copies to make room for the ghosts.

A ghost schedule and a primary schedule are said to be feasible pair if all
deadlines continue to be met even if the primary tasks are shifted to the right by
the time needed to execute the ghosts. Ghosts may overlap in the ghost schedule
of a processor. If two ghosts overlap, only one of them can be activated. There
are two conditions that ghosts must satisfy.
C1. Each version must have the ghost copies scheduled on nsust distinct
processors. Two or more copies (primary or ghost) of the same version must
not be scheduled on the same processor.

C2. Ghosts are conditionally transparent. That is, they must satisfy th following
two properties:

a. Two ghost copies may overlap in the schedule of the processor if no other
processor carries a copy of both tasks.

b. Primary copies may overlap the ghost in the schedule only if there is
sufficient slack time in the schedule to continue to meet the deadlines of
all primary and the activated ghost copies on that processor.

Conditions C1 and C2 are necessary and sufficient conditions for up to nsust

processor failures to be tolerated.

Algorithm FA provides the fault tolerant scheduling algorithm.

Algorithm FA.

1. Run πa to obtain a candidate allocation of copies to processors. Denote by

πi and θi primary and the ghost copies allocated to processor pi ,
i=1……,np. For each processor, pi , do steps 2 and 3.

2. Run πs*( πi U θi , i). If the resultant schedule is found to be infeasible, the

allocation as produced by πa is infeasible; return control to πa in step 1.
Otherwise , record the position of the ghost copies in ghost schedule Gi.
Assign static priorities to the primary tasks in the order in which they
finish executing i.e. if primary πi completes before πj in the schedule
generated in this step, πi will have higher priority than πj.

3. Generate primary schedule Si by running πs2 on πi , with the priorities

assigned in step 2.

In this algorithm we use an additional scheduling algorithm πs2, which is a static

priority preemptive scheduler. That is, given a set of tasks, each with its own
unique static priority, πs2 , will schedule them by assigning the processor to
execute the highest priority task that has been released but is not yet completed.
 DATABASES FOR HARD REAL TIME SYSYTEMS

We describe an experimental hard real time database system that departs from
the client server model, MDARTS, and use it as a vehicle to demonstrate how
hard real time databases may be constructed.

MDARTS stands for multiprocessor database architecture for real time systems.
It is meant primarily for control applications such as controlling machine tools
or robots. MDARTS is a library of C++ data management classes, and is an
object-oriented system. The real time constraints of the application are specified
in the object declarations. These include two string parameters, a unique object
identifier and a set of semantic and timing constraints. The timing constraint is a
bound on the execution time plus the blocking time for operations on that
object. Since the same object can support multiple operations ( eg. An array can
support the operation “return the minimum of array” and “return the first
element of the array”, among others), MDARTS allows a timing constraint to be
associated with each operation.

Each of the data management classes has a certain performance characteristics

and certain capabilities. Based on these and other constraints, MDARTS can
choose a data management class that is best suited to the needs of that object.
For example, if it is specified that a particular object will only be updated by
one task, the system might choose a database class that is best for single writer
control. That is, since the system knows that there is a single writer, concurrent
updates are impossible. As a result, the system needs not use in connection with
this class any of the locking machinery associated with managing concurrency.
This can save considerable overhead and make it easier to meet hard deadlines.

When an application declares an object, the system sends the relevant

information to the shared data manager (SDM) server. Associated with each
class name is an exemplar, which is an instance of that class. The SDM then
searches trough its library of exemplars for one that meets the application
constraints. If no such exemplar is available, the SDM reports failure. If such an
exemplar is found, the SDM clones it to create a new object of that type,
allocates shared memory as appropriate, sets all the associated pointers and
returns the object type and shared memory information. Shared memory can be
encapsulated using the object oriented approach.
MDARTS does not use the standard relational database model. Instead, each
object provides context and identity for its data. MDARTS objects use direct
memory pointers to their data. Critical sections are guarded by spinlock queues
in multiprocessors and the locking is managed by the system, not by the
application. A task that is waiting for a lock or is executing its critical section is
not preempted; this helps bound priority inversion. MDARTS does not allow
transactions to contain multiple database operations. Instead, a transaction
executes the code within a database object. MDARTS can reserve resources for
transactions in advance to ensure that hard deadlines are met. This keeps
guarantees valid, even if temporary overloads happen.

MDARTS has an interesting way of checking for execution time requirements.

There is a function called calibrate() which runs a set of experiments on the
database operations to determine how long each operation takes.

Let us now consider another approach to hard real time systems. An alternative
to associating each transaction with a deadline is to place a limit on how long an
application can be allowed to be in certain dangerous states, and to schedule the
transactions appropriately. Deadlines need not to be associated with
transactions, but with the time allowed to bring a system out of an unsafe state.
When the controller is built around the database, there are three kinds of
transactions:

External-input transaction: These are the transactions that record external

events in the database. Such transactions are usually write-only.

Internal transactions: The purpose of this type of transaction is to run

application tasks to help control the process. Internal transactions may be
nested. That is, if it is possible for a transaction to call another transaction,
which itself calls yet another transaction, etc.

External-output transactions: These are the transactions by which the computer

system specifies the action to be taken. External-output transactions may be
periodic or speriodic.

External-output transactions report the output generated by internal transactions

and can be scheduled immediately after them. Internal transactions can be
scheduled, not with respect to individual deadlines but in such a manner as to
bring the controlled process into a desired state within an overall deadline.
Which transactions are actually scheduled to be run depends on the deadline,
the transaction run times, and the current and desired states of the controlled
process.