Integration of real-time and consistency constraints in distributed databases: The sigma approach

97

Integration of Real-time and Consistency Constraints in Distributed Databases: The SIGMA Approach Pascale M I N E T a n d Simone S E D I L L O T INRIA, Domaine de Voluceau-Rocquencourt, B.P. 105, 78153 Le Chesnay Cedex, France

The association of distributed databases with automated process control as described in section 1 sets the problem of establishing consistent transactions schedules which are compatible with real-time constraints. Both data consistency and real-time scheduling are domains which have been largely investigated but separately. This paper addresses the two problems together and shows that a unique approach is possible. A common synchronization mechanism is used to solve respectively the data consistency problem and the real-time scheduling problem. An implementation on the SIGMA prototype is described as well. Keywords." Real-time, Distributed Data-Base, Consistency, Scheduling, Priority, Promptness.

M i n e r received her engineering diploma in Computer Science in 1980 from ENSEEIHT at Toulouse, and her thesis of doctor engineer in 1982 from the University of Toulouse. She is actively concerned with distributed real-time systems within the research project SCORE at INRIA Rocquencourt, France. Her main concerns are real-time communication, local area networks, standardization, real-time transport services and protocols, concurrency control in distributed systems, reliability and fault tolerance. Paseale

S i m o n e Sedillot received her engineering diploma in Electronics in 1964 from ESME in PARIS. She successively worked in the areas of networking in the CYCLADES project and concurrency control in the SIRIUS project within INRIA, from 1972 to 1980. Presently, her main concerns is message and distributed tasks scheduling in a real time local area network environment.

North-Holland Computer Standards & Interfaces 6 (1987) 97-105

1. Real-time

Distributed

Databases:

The

Context

T h e association of distributed databases with a u t o m a t e d process control relies o n the following observations. A l t h o u g h sensors a n d actuators are specific to the real-time e n v i r o n m e n t , they can be assimilated to files a n d records for the c o m p u t i n g system, the e n v i r o n m e n t interface b e i n g viewed as a n y data physical support. Just as it is in distributed databases, a real-time t r a n s a c t i o n is defined as a set of inputs, processing actions distributed over computers a n d o u t p u t s that m u s t be kept consistent. But the real-time e n v i r o n m e n t implies also timing constraints o n t r a n s a c t i o n executions such as start times, due dates, execution delays. H e n c e a real-time distributed database system m u s t ally c o n c u r r e n c y control a n d scheduling services, a n d meet the constraints described thereafter. Correctness comprises C O N S I S T E N C Y [1-6], P R O M P T N E S S [7] a n d A T O M I C I T Y [8,9]. C o n sistency a n d atomicity have been largely investigated in distributed databases. P r o m p t n e s s is related to real-time constraints which define for each t r a n s a c t i o n actions p a r a m e ters such as: - its earliest start time EST, - its latest start time LST, - its m a x i m a l allowed execution time X, - its due date D o. 1.1. Static priority The t r a n s a c t i o n static priority is fixed b y the user. It is a constant. W e define U R G E N T transaction as having a static priority of zero a n d R E G U L A R t r a n s a c t i o n s as having a static priority greater t h a n zero. 1.2. Resources characteristics T h e t r a n s a c t i o n defines the A C C E S S M O D E for each required data a n d it requires a S T A T I C

0920-5489/87/$3.50 © 1987, Elsevier Science Publishers B.V. (North-Holland)

P. Minet, S. Sedillot / The Sigma approach

98

or a D Y N A M I C resource allocation. In the case of static allocation, a transaction execution cannot start before all its resources are granted. A static allocation implies an a-priori knowledge of all accessed data. In the following we assume that resource allocation is either static or dynamic at the transaction level but always static at the action level. Also, the transaction may require an execution G U A R A N T E E or not. A transaction is said to be guaranteed if the system has taken the engagement that this transaction will have all its resources (accessed data and CPU) at the time it is scheduled and for its execution duration. 1.3 Robustness characteristics They define what must be done when a fault occurs (promptness violation, unavailability, etc. Fault tolerance strategies can be defined either at the transaction or at the action level: exceptions signalling, return to previous consistent state, - recovery block execution [10], masking by voting on multiple instantiations.

2.

Data

Consistency

2.1. The problem It is well known that a sufficient condition (but not necessary) [1,11] to ensure data consistency with parallel execution is that transactions must be executed in a S E R I A L I Z A B L E way. Without conflict any execution is serializable. A CONF L I C T occurs as soon as two actions belonging to two different transactions want to simultaneously access the same object in incompatible modes. Because of the unpredictable arrival time of aperiodic transactions, conflicts cannot be avoided, and must be solved. This means that conflicting accesses must be serialized in a consistent way. In order to increase the C O M P A T I B I L I T Y with the real-time constraints attached to the actions, any concurrency control algorithm must meet the following requirement RRT: RRT: the serialization constraint induced by the need to preserve data consistency must be as few limiting as possible.

2.2. The Adopted Approach 2.2.1. What must be done From RRT it follows that - the compatibility among the access modes must be increased as much as possible - the concurrency control algorithm must serialize only conflicting actions - the conflict resolution rule must be adapted to real-time. 2.2.1.1. Access Modes Compatibility In order to decrease the conflict probability and hence the waiting times, the compatibility between simultaneous accesses can be increased by: - defining three access modes: READ: WRITE: the object receives a new value which does not depend on the previous one R E A D WRITE: the computation of the new value takes into account the previous one maintaining the object in several versions. T h e c o m p a t i b i l i t y between s i m u l t a n e o u s accesses from actions A and B is given by Table 1: 2.2.1.2. Choice of the Concurrency Control Algorithm A P A R T I A L O R D E R I N G is adopted that serializes only conflicting transactions. The objects are maintained in SEVERAL VERSIONS [2] which are totally ordered. Each version is named by the timestamp of the transaction which created it. This increases the compatibility of simultaneous accesses as shown in Table 1. 2.2.1.3. Conflict Resolution Rule The conflict resolution rule is applied in order to decide of the serialization order of the two conflicting actions. A global conflict resolution rule provides the same serialization of any two transactions on all the sites where they conflict. This ensures that only one transaction among the two has a delayed execution. At time t at which the conflict is detected, the D Y N A M I C P R I O R I T Y H ( T ) is computed for each conflicting transaction T. The transaction with the smallest dynamic priority wins the conflict. The function H ( T ) is a product of three terms: 1 t ( 7 " ) = (1 - a ( r ) )

• [j(r)

• (1 - V ( T ) )

+ I, • (D,,(r)

- t)]

P. Minet, S. Sedillot / The Sigma approach Table 1 Compatibility table A

B

Read Write Read Write

Read

Write

Read Write

Y Y* Y*

Y* Y Y*

Y* Y* Y*

Y = always compatible. Y* = compatible only for different object versions.

The first term is concerned with transaction guarantee in the sense of Section 1.2.3. G ( T ) --

1 0

if the transaction is guaranteed otherwise.

The second term is concerned with transaction commitment: V(T) =

1 0

if the transaction is committed otherwise.

The third term combines: - the static priority j defined in Section 1.2.2. - a time-dependent priority which takes into account the remaining time before the transaction due date Dd; smaller is the system parameter k, greater is the influence of the static priority relatively to real-time constraints attached to the transaction. If k is chosen such as 0 < k * I Dd(T) - t[ < 1 for any T, then the third term is always smaller for urgent transactions than for regular ones. Such a conflict function ensures that a committed or guaranteed transaction will always win a conflict. Notice that a committed or guaranteed transaction can only conflict with a transaction neither committed nor guaranteed. If a conflict occurs between two transactions neither committed nor guaranteed, the transaction with the smallest priority wins the conflict.

2.2.2. How It can be done 2.2.2.1. Distributed Control For performance, robustness and flexibility reasons distributed control mechanisms [12] have been chosen. Every transaction execution is monitored and controlled by a coordinator; at a given time several coordinators may coexist in the system, each of them being in charge of one transaction. Sites work asynchronously: each of them builds alone

99

the serialization using the same conflict resolution rule. A local site may decide itself to abort a transaction (we speak of transaction cancellation) except when a conflict is detected with a transaction T currently involved in guarantee or commitment protocol. The local site must then ask for an abort to T coordinator. If the coordinator agrees, it broadcasts the abort order to all sites involved.

2.2.2.2. An Optim&tic Approach An optimistic approach [4,13] allows anticipation in transaction execution and reduces the waiting times. This is why it has been adopted for real-time systems.

3. Real-Time Scheduling 3.1. The Problems In environments of either n machines [14, (Ch. 6)] or one machine [15], it is impossible to find a scheduling algorithm guaranteeing that all action executions will meet their due date if the action start time distribution law is unpredictable. Moreover, scheduling policies have been mostly investigated in the job-shop domain. Hence they assume that all jobs must be executed, the performance criteria being to minimize either the job m a x i m u m lateness [16,17], the shop life time [18-20], or the number of late jobs [21]. Only a few proposals (e.g. [22] and [23] consider nonconservative hard real-time systems whereby a task is rejected when it cannot be scheduled before its latest start time, the performance criteria being the number of rejected tasks [24]. But both [22] and [23] assume, first, that each task consists of one action and, second, that a task earliest start time has elapsed at the time the scheduler processes it. When a task is extended into a set of distributed actions with different earliest start times - as in our case - it becomes impossible to guarantee a transaction before its action with the latest earliest start time is scheduled. Since this is precisely one of our objectives, actions must be scheduled before their earliest start time.

3.2. The Adopted Approach Scheduling is decentralized. There is a scheduler in each site. It schedules only actions that must be executed locally.

100

P. Miner, S. Sedillot / The Sigma approach

A scheduler determines a new action schedule as soon as it receives its context. Action A schedule consists of two time values. The scheduled earliest start time SEST(A) and the scheduled latest start time SLST(A). Any time t between and including these two bounds is a correct time to start the action execution. The value of SEST(A) can be modified provided that its new value does not exceed SLST(A). Reciprocally, SLST(A) can be modified provided its new value is not smaller than SEST(A). This permits to insert a new action between two already scheduled actions A i and Ai+ 1 and still guarantee A, and Ai+ 1 executions. Possible places where to insert a new action are restricted to those that respect both the new action earliest start time and its precedence constraints as expressed by the concurrency control. A possible place is a C O R R E C T place if the following relation is satisfied: SLST(Ai) + X ( A ) -~I 1. The scheduler must either refuse to schedule A or abort the p actions. To decide which of the solution must be selected, the scheduler uses the actions dynamic priority as it is defined in Section 2.2.1.3 and applies the following rule: - A is rejected if for all possible places, at least one of the p actions has a lower transaction priority than A's. - Conversely, if, for at least one place, A has a higher transaction priority than any of the p actions, - in particular it means that none of the p actions belongs to an already guaranteed transaction - the scheduler initializes a two-phase abort protocol with each of the p actions transaction coordinators. If each of these accepts the abort, the p actions are unscheduled and A is scheduled. Otherwise, A is rejected. The two-phase abort protocol ensures that all actions of a transaction are aborted or none. This is essential for the transaction atomicity. One should note that even though scheduled

earliest and latest start times can be modified, the relative ordering of scheduled actions is never altered. This spares precedence constraints checking overhead.

4. The Sigma Experiment This section describes some aspects of the S I G M A executive. We first list basic mechanisms used by the concurrency control and the scheduling algorithms. These algorithms are described. Executive architecture is then presented and a transaction execution in S I G M A is shown. 4.1. Basic Mechanisms Four mechanisms (not described here) provide basic blocks to the executive: 1. Computers physical clocks are synchronized [25]. Clock time is thus defined with a given accuracy. 2. The communication subsystem guarantees an upper bound for message transmission delays. 3. At their submission time, transactions are timestamped by there due date. 4. Concerning fault tolerance, the occurrence of faults is detected and S I G N A L L E D to users. The system provides C O N S I S T E N T RECOVERY. 4.2. Concurrency Control Algorithm Concurrency control is exercized in four phases: Phase 1: determines which version the requesting action will access, and resolves the detected conflicts. Phase 2: expresses the precedence constraints attached to the action, Phase 3: guarantees a consistent access to the requested objects, Phase 4: commits the transaction. 4.2.1. Phase 1: Determination of the Accessed Version 4.2.1.1. Structure of the access table For each object an access table keeps track of all the object accesses belonging to the short term of the system (including past, present and future). Each object version is timestamped by the due date (and not by the arrival time as in [2]) of the transaction

P. Minet, S. Sedillot / The Sigma approach

which created it. The due date of the transaction A i belongs to determines the version accessed by A i•

Note that a written value may be read before being committed. This is a feature of the optimistic approach which is not allowed in [2]. The structure of the access table is given in Table 2. 4.2.1.2. Insertion rules in the access table: The relative order of two transactions in the object access table is never changed but insertions are allowed. Insertion A i is accepted if its rank in the access table is: either at the end of the table - or before actions Aj which are not yet executed - or before actions Aj which are already executed, but whose execution does not depend on the execution order between A i and A j . The only conflicting case is when A i ought to be inserted before Aj already executed and A i would modify the value read by Aj. Such a conflict is won by the action belonging to the transaction T with the smallest H ( T ) . The other action is either rejected if it was the requester A i otherwise Aj is either cancelled or its abort is requested to its coordinator if it has entered either the guarantee or commit protocol. In the last case A i insertion is accepted only upon Aj abort reception. Figure 1 summarizes this algorithm. Real-time constraints are taken into account by this algorithm: the due date orders the transactions in the access table the due date takes part in the computation of the conflict function - more generally the algorithm provides results identical to those obtained by a serial execution of the transactions according to their due date (this indicates that consistency is achieved). -

-

-

4.2.2. Phase 2: Precedence Constraints Expression In order to increase the probability that,

101

according to the scheduling rule, the scheduler finds a place where to insert the action, the only precedence constraint is: if action B must read the version written by A, then action B must be scheduled after action A. For instance the precedence constraints derived from Table 2 are expressed in the "scheduled after" column: TsA 3 and TsA = must be scheduled after T2A 1 but there is no relative order between T s A 3 and T s A 2. 4.2.3. Phase 3: The Objects Guarantee The notion of guarantee does not exist in classical distributed databases, but is related with realtime. 4.2.3.1. Guarantee rules Rule RI: A guarantee is granted to an action A if each object requested by A can be guaranteed. Rule R2: A required object is guaranteed by the concurrency control if the associated action has been scheduled - the object is required: either in write mode or the read version (access mode = read or read write) has been created by a transaction either commited or guaranteed. Rule R3: As soon as the action is guaranteed by concurrency control, it is said to be locally guaranteed and the two phase guarantee protocol is entered (see Section 4.4.). As insertions before guaranteed actions are allowed, Rule R4 is necessary Rule R4: If action A creates a version which is later read by an action B belonging to a guaranteed transaction, then B start causes the abort of A if A belongs to a transaction neither guaranteed nor committed. -

Table 2 Object access table Name

Due date

Statis priority j

Committed

Guaranteed

Executed

Access mode

Sched after

Object value

T2.A1 T5.A3 T8.A2

2 5 8

0 5 3

1 0 0

0 1 1

1 1 0

W R RW

/ T2.A1 T2.A1

- 1 - 1 /

P. Minet, S. Sedillot / The Sigma approach

102

done. This algorithm ensures that committed or guaranteed transactions are never undone.

:i::: ):: :: }:::::::::::>::::::::::::::::::::::::::::::::

', 4.3. The Scheduling Algorithm

l

No[

1 Insert Af

4. 3.1. Delimitation of Possible Places Possible places for insertion of action A must respect the precedence constraints and A's earliest start time EST(A) as well as A's latest start time LST(A). Given a precedence constraint such as A t --*A 2 ---~A - * A 3 --* A4, EST(A) and LST(A) are updated according to the two following rules: new EST(A) = max ISEST(Ai) + X ( A i ) , EST(A) [ for i = 1 and 2

Yes[

Insert Ai

================================================================================

beinQeilherii!i?I ~.¢brnmittedor guaronteed::: :i:::!:!!::) No Conce] Aj (Aiin 0r0Qress 0f

new LST(A) = min ISLST(A,) - X ( A ) , LST(A) [ for i = 3 and 4. At this point, A is rejected if new EST(A) > new LST(A). Assuming that already scheduled actions Aa, A2... Ap are such that SEST(Aa) _< new E S T ( A ) < SEST(A2) _< SEST( A e ) <_new L S T ( A ) _< S E S T ( A p + 1),

Ask Ajabort to its Coordinator

Fig. 1. Insertion of A i in the Access Table.

then, each of the times t~ is a possible place, where

t i = max[new EST(A), SEST(Ai) + X(Ai) [ for 1 ~< i,<
4. 3.2. Determination of Correct Places All values of i such that t~ + X ( A ) <_SLST(Ai + 1)

4.2.4. Phase 4: Conditional Commitment The C O N D I T I O N A L C O M M I T M E N T R U L E is as follows: A transaction can be committed only if every read version has been created by a transaction already committed. For instance T5 from Table 2 can be committed because T2 is committed. Note that there is no possible deadlock [13] because of the total ordering of transactions due dates. This is a basic difference from classical optimistic approaches. This algorithm takes into account real-time constraints by allowing execution anticipation, which is impossible with a conventional two-phases locking protocol [9]. If a transaction must be undone, then all the transactions which read a version created by this transaction must be un-

(1)

(2)

are correct places. If any exists, the smallest value of i is chosen and SEST(A) is made equal to t~. A is scheduled, and the schedule update procedure is invoked. If there exists no correct place, the conflict resolution rule is invoked.

4.3.3. The Current Schedule Update The insertion of A after A i implies updates of the scheduled earliest start times for A's successors A~+2... Ai+ ., according to the following rule: if SEST(Ai+,) + X ( A , + , ) > SEST(Ai+,+I) then SEST(Ai+,+I) = SEST(Ai+,) + X(Ai+,).

(3)

Likewise scheduled latest start times for A pre-

P. Minet. S. Sedillot / The Sigma approach decessors A~, A~_~, Ai_ . are updated according to the following rule: if SLST(A,_~) - X ( A ~ _ , _ ~ ) < S L S T ( A , _ , _ ~ ) then SLST(A/_,,_I) = SLST(Ai_,,) - X ( A i _ , _ t ) .

(4)

4.3.4. The Conflict Resolution Rule Since relation (2) is not satisfied, it means that for each t~ S L S T ( A i + I ) < ... < S L S T ( A i + p ~ ) < t i+ X ( A ) where p~ is the number of the action that must be unscheduled if A is started at time t~. The conflict resolution rule acts as follows: Any of the i values such that the p, actions have a dynamic priority value greater than A's are possible values. A m o n g these, the value imi. providing the minimum value of p~ is chosen. When the abort protocol is completed for all actions -

103

A~+~. . . . . A~+e, A is effectively inserted and the current schedule updated. Note that the abort protocol implies an updating of the current schedule depending on the impact of the suppressed actions on their predecessors and successors SESTs and SLSTs. For each suppressed action, rules are applied that advance its successor's scheduled earliest start time if possible and delays its predecessor's scheduled latest start time if possible. These rules are derived from rules (3) and (4). - If no value of i corresponds to p, actions which priority values higher than A's, A is rejected. 4.4. Transaction Execution in S I G M A S I G M A is a prototype built on three PDP11s interconnected together via D E C N E T and running under RSX-11M. RSX-11M has been modified so as to include the executive which is needed to achieve our goals (see Figure 2).

P1 A C H I N E

. . . . . . . . . . . .

.........

Manager~:i:!:!:i:i

c H N

I ~ I I 4, I I 4, I Actions [----I 12--'-I ........ ~1 Precedence ~ ~ ~ Co~traint~

I*l I~,l I--"t H ~

"

I ~ , l Acti°ns H Precedence ........ ~ Constraints

o3.1 x.~....i= ............ J . . 03.r~ 7

3 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

...............

~

~

Time Scale

(>

~1¢~ Time Scale

) -............,........:.............,............

,......

Fig. 2. SIGMA Executive Architecture. Note: All machines may have the same functionalities. It is only for simplicity reasons that all processes have not been represented.

104

P. Minet, S. Sedillot / The Sigma approach

Assume a transaction T has "arrived" at time t at site i. T can be predetermined or not. At that time, the transaction generator timestamps T with its due date and creates T ' s actions contexts according to T ' s characteristics. Usually, the coordinator of T is located in the same site as the generator of T since the coordinator ensures the contexts remote loading on the computers on which they must be executed. Note that an action context contains the indication of the execution action location. Local transaction managers receive actions contexts and invoke the concurrency control. When scheduled, concurrency control and scheduler allocate resources to the actions. The T coordinator ensures the transaction monitoring and controlling, that is it coordinates its guarantee, commitment and abort protocols as shown in Figure 3. Otherwise, control is fully decentralized and left to local concurrency control, scheduler and real-time monitor processes. The real-time monitor runs asynchronously from the concurrency control and scheduler process. Its functions are to allocate CPU at current time and pre-empt actions that exceed their maximal allows execution time, according to the current schedule. A local action manager acts asynchronously from concurrency control and scheduler. It takes in charge messages exchanges - i.e. logical synchronization - between actions. The action manager is activated at the end of every action execution. The induced overhead is accounted for in evaluation of X(A).

Local Guarantee (At)

Ai scheduledwith each • Objecl access guaranteed by Concurrenc~ Control

Guarantee (T)

Fig. 3. An Example of the Guarantee Protocol. Note: The abort protocol is based on the same principle.

5. Conclusion This paper described an approach to consistent schedules of distributed transactions actions meeting real-time constraints. Each site has a SYNC H R O N I Z A T I O N S C H E D U L E R (consisting of concurrency control and real-time scheduling) which autonomously allocates local resources (objects and CPU) to the actions according to their real-time constraints and to distributed database consistency. Conflicts among actions are solved by comparison of the involved transactions' dynamic priorities. Precedence constraints and scheduled start times are kept as flexible as possible in order to allow future action insertions without reordering the currently scheduled actions. As both concurrency control and scheduler use the same conflict resolution rule they tend to minimize the number of transactions aborted for promptness reasons which is the adopted performance criterion. The transaction coordinator ensures transaction atomicity with regard to guarantee and commitment.

Acknowledgements The authors wish to thank the SCORE Project members G. le Lann and J. Boudenant for their fruitful discussions and encouragement, J.M. Proth for his help in drawing out the real-time scheduling inherent complexity and the SCORE secretariat.

References [1] K.P. Eswaran, J.N. Gray, N.A. Lorie and I.L. Tralger: "The notions of consistency and predicate locks in a database system", Communications of ACM, Vol. 19, no. 11, pp. 624-633, November 1976. [2] D.P. Reed: "Naming and synchronization in a decentralized computer system", MIT Dept. of Electrical Engineering and Computer Science, Ph.D. Thesis, September 1978. [3] P.A. Bernstein and N. Goodman: "Concurrency control in distributed database systems", ACM Computing surveys 13, 2, pp. 185-221, June 1981. [4] P.A. Bernstein and N. Goodman: "Multiversion concurrency control - theory and algorithms", ACM Transactions on Database Systems, Vol. 8, no. 4, pp. 465-483, December 1983. [5] R.H. Thomas: "A solution to the concurrency control problem for multiple copy data bases", COMPCON 78 Spring.

P. Minet, S. Sedillot / The Sigma approach [6] L. Sha, J.P. Lehoczky, E.D. Jensen and N. Pleszkoch: "Data consistency and transaction correctness ... a modular approach to non-serializable transactions", CarnegieMellon University, August 1983. [7] G. le Lann: " O n real-time distributed computing", IFIP Congress 83, September 1983,. Rapport INRIA SCORE GAL-I-006. [8] J.R. Davies: "Data processing integrity", IBM San Jose, December 1971. [9] J.N. Gray: "Notes on database operating systems", Lectures notes in Computer Science, Vol. 16, Springer-Verlag, New York, 1978, pp. 393-481. [10] L. Svobodova: "Resilient distributed computing", IEEE Transactions on Software Engineering", Vol. SE10, no. 3, May 1984. [11] P.A. Bernstein, D.W. Shipman and W.S. Wong: "Formal aspects of serializability in database concurrency control" IEEE Transactions on Software Engineering DE-5, no. 3, May 1979. [12] G le Lann: "Algorithms for distributed data sharing systems which use tickets", 3rd Berley Workshop on Distributed Data Management and Computer Network, August 1978. [13] C. Boksenbaum, M. Cart, I. Ferrie and J.F. Pons: "Certification par intervaUes d'estampilles dans les systrmes rrpartis", Universit6 des Sciences et Techniques du Languedoc, Montpellier, June 1983. [14] R. Conway, M. Maxwell and L. Miller: "Theory of scheduling", Addison-Wesley Publishing Company, April 1967. [15] A. Ka-Lan Mok and M.L. Dertouzos: "Multi-processor scheduling in a hard real-time environment", Proceeding of the 9th Texas Conference on Computing Systems, IEEE Editor, Nov. 78, pp. 5.2-5.12.

105

[16] W.S. Gere, "Heuristics in job shop scheduling", Management Science, Nov. 1966, Vol. 13, no. 3, pp. 167-190. [17] J.P. Soubrier, " U n modrle de rrsohitions de problrmes d'ordonnancement dynarnique", Thrse de Doctorat, Universit6 Paul Sabatier, Toulouse, 1981. [18] P. Bratley, M. Florian and P. Robillard: " O n sequencing with earliest starts and due dates with applications to computing bounds for the ( n / m / g / F m ~ ) problem", Naval Research Logistics Quarterly, March 1973, Vol. 20, no. 1, pp. 57-67. [19] M.I. Dessouky and C.R. ~¢largenthaler: "The one-machine sequencing problem with early starts and due dates", AIIE Transactions, Vol. 4, 1972, p. 214-222. [20] K.R. Baker: "Sequencing with due dates and early start times to minimize maximum tardiness", Naval Research Quarterly, March 1974, Vol. 21, pp. 171-176. [21] R. Conway: "Priority dispatching and job lateness in a job shop", The Journal of Industrial Engineering, JulyAugust 1965, pp. 228-237. [22] Derville, Kaiser, Peirotes, Tellier: "Le syst~me HALIOTIS", R.I.R.O. 1967, no. 6, p. 3.25. [23] W. Zhao, K. Ramamrithan and J.A. Stankovic: "Scheduling task with resource requirements in hard real-time systems", Internal Report, Electrical and Computer Engineering Department, University of Massachusetts, May 1984. [24] M.C. Costa, G. le Lann, J.F. Meyer and S. Scdillot: "Real-time local area networks: some design and modeling issues", INRIA Research Report, to be published. [25] L. Lamport: "Time, clocks and the ordering of events in a distributed system", Communications of the ACM, Vol. 21, no. 7, pp. 558-565, July 1978.