A Scheduling Strategy to Preserve Object Autonomy

Copyright Cl IFAC Real-Time Programming, Palma, Spain, 2000

A SCHEDULING STRATEGY TO PRESERVE OBJECT AUTONOMY

Jose Lino Contreras, Jean Louis Sourrouille

L31: Laboratoire d'lngenierie de l'lnformatique Industrielle INSA, Bat. 502, F69621 Villeurbanne Cedex - FRANCE E_mail: {sou,jcontrer}@ifinsa-Iyonfr Phone: (+33) 4 72438743 Fax: (+33) 4 72438518

Abstract. This article descnbes an active object model and its scheduling strategy to fit with realtime applications. In this model, objects are autonomous and adaptive, since they run without centralized control and they adapt their behavior to their execution context. Within the soft RT domain, this work focuses on object autonomy and scheduling. Optimal management of shared resources requires a centralized solution. But object orientation assumes distributed architectures and some important basics, such as encapsulation and autonomy, are threatened by centralized approaches. As a compromise, the proposal has both, centralized and decentralized decision levels. Copyright \0 2000 IFAC.

(Rn

Keywords: scheduling algorithms, objects, adaptive systems, meta-level knowledge, fault tolerance, Real-time systems.

(Adaptive Active Object, Contreras and Sourrouille, 1998), is applied to cope with timing faults.

1. INTRODUCTION Real Time (RT) systems are typically classified as hard or soft. In hard RT systems all time constraints must be respected always and scheduling policies must ensure this requirement. Any other case is seen as soft RT, whose scheduling goals are often expressed as "to minimize mean tardiness", "to maximize summed utility", etc.

Optimal management of shared resources, such as cpu time, demands centralized decision making, while object orientation assumes a distributed architecture where each object takes its decisions independently. Centralized approaches threatens some basics of 00 such as independence and encapsulation. As a solution, the authors propose a compromise between distribution and centralization through a two level decision approach. At local level objects make autonomous decisions on message executions and at global level a general scheduler considers the messages selected by all AAO's to manage the cpu.

In many RT systems, temporal properties are guaranteed by frozen scheduling policies deduced from static analysis of the system. In spite of its great safety, this technique does not distinguish between tasks of different nature, such as critical and non critical (Stankovic and Ramamritham, 1993), and fails when task arrival dates are unknown. In this last case, dynamic scheduling is a better approach (see Leung, 1991) and static analysis can help to ensure some system properties, such as the correct execution of important tasks. In this context (soft RT with unknown arrival dates), the active object AAO

The context of the project is similar to "Design to time... " (Garveyand Lesser, 1993): - There is not necessarily enough cpu time to execute all requested services, - There are both soft and hard time constraints,

143

-

-

Several methods with different quality are sometimes available to provide the same service, Decision rules guide method selection under overload, Non optimal scheduling is expected when the system is overloaded, but important tasks should be executed, Predictability of method deadlines and cpu time requirements is good while predictability of request arrivals is low or even null.

Active object 1

Active object2

Execution of M

Call to M

The expected underlying architecture is very general: several computers, operating systems managing threads (dynamic priorities and preemption), communications and names across the network.

!02-+M(par)

translated into

MOl-+Send(M02,M,par)

Figure 1. Message sending.

To catch and analyze messages before processing, To control concurrent execution of methods, To monitor the object behavior to make decisions according to its execution context.

This article is restricted to a single-processor computer and focuses on the two level decision framework rather than on scheduling policies. In the following sections, the main features of the active object model are introduced. The scheduling problem raised by object independence and the proposed solution are then described. Finally, results both from simulation and prototype experiments are shown.

Implementation of the AAa. The implementation is based on objects and metaobjects, structured in two levels (Fig. I). The base level code deals with the user problem, and is independent of the execution context. At meta level, metaobjects deal with al1 that is context dependent (scheduling, concurrency, message passing, etc.). Every object has a link to its metaobject and conversely each metaobject has a link to its object (Fig. I). Each one deals with problems of its specific domain and strictly conforms to the encapsulation principle. Each active object class is associated with one (or more) metaobject class that lies within the inheritance graph.

2. AUTONOMOUS ACTIVE OBJECTS

2.1. Adaptive Active object

AAOs control their method executions to deal with concurrency and temporal constraints, and to manage resource conflicts. The active object holds several threads and executes its methods concurrently. It has a local control1er that keeps received messages in a queue and decides about their treatment. In this model, the active object notion is kept for autonomous and independent objects, with a long life span. Passive objects are encapsulated into active objects and do not introduce concurrency.

The AAO metaobject controls a few base level mechanisms only: creation/destroying of active objects, message sending, and access to the object's attributes. As an advantage it doesn't require any special programming language or special feature. Communication between AAOs. AAOs communicate via messages only: neither event nor semaphore or mailbox are offered (events are implemented as messages). In AAOs, messages are replaced by the special message Send (whose parameters include the original message), which is sent to the object's metaobject (Fig. I). In this way, the original message is control1ed by the sender metaobject, which decides what to do with it (norrnal1y, to send it to the planned receiver metaobject, but any other action is possible). The receiver metaobject usual1y executes the method invoked in the message, but any other decision can be taken. The sender metaobject receives the reply that takes the opposite path (Fig. I).

2.2. Implementation The AAO architecture. The architecture is based on a reflective meta-Ievel architecture. A system is reflective when it holds a self-representation on which it operates to modify its behavior (Smith, 1982). To implement reflective systems, meta level architectures have been proposed (Maes, 1987; Chiba and Masuda, 1993). The general idea is that any base level provides mechanisms, whose implementations are held by its meta level. Acting upon this implementation, the meta level modifies the base level behavior.

Message processing. AAOs manage a queue of received messages. Messages go through filters and those capable of being served in the context are selected (Fig. 2). This process is repeated as long as a queued message can be executed.

The main ideas behind the AAO's architecture are: To separate the reusable part of the object from all that depends on the application context,

144

-

-

-

-

Message/method-set mapping. The message is first associated with an action. If the action is a metaobject service, the message is processed immediately. When an object service is required, the message is associated to a set of methods (alternative services), built according to the current object mode (starting, normal, emergency, landing, etc.) and to the message characteristics. State filter. At any moment the state of the object defines the allowed methods. Forbidden methods are rejected. Intra object concurrency. Two methods m and m' that can not be executed concurrently are said to be incompatible. They can be executed simultaneously only if m caIls m', directly or through other methods. Methods incompatible with those currently scheduled are rejected. Additional filters. These filters cope with other concurrency conflicts like resource sharing or inter-object method incompatibilities. Any other specific user filter is also possible. Local scheduling. Messages that pass all filters are candidate for execution. One message is chosen according to the local scheduling policy, associated with a thread, and scheduled with the selected messages of all AAOs.

otherwise the general problem is NP-complete (a survey in Stankovic, et al., 1995). When overloaded, decisions can be guided by the number of temporal faults, the methods importance or the result quality. According to the favored criterion, two policies are: - To provide high services quality: when the system is overloaded, provided services keep the maximal quality while lower quality services are not provided. The drawback is the increase of temporal faults. - To reduce temporal faults: the basics of this policy is that any result, even approximated, is better than no result at all. To provide services on time, quicker available methods are executed at the cost of a lower quality of service. As a last resort, less important services are canceIled (graceful degradation). The chosen policy is "to reduce temporal faults", specially for its greater adaptability potential.

3.2. Centralized/decentralized scheduling As stated previously, a centralized scheduling policy provides the best resource utilization but breaks basics principles of 00 approach. By the other side, the sum of independent local policies would lead to unpredictable and non optimal results. So, the two levels scheduling solution aims to integrate both approaches: independent decisions at local level, and centralized decisions at global level.

3. SCHEDULING In AAOs, messages are mainly characterized by deadline, importance, periodicity, and nature of the requested service. Knowing these parameters as well as method characteristics (quality, duration, resources, etc.) and the execution context, the decision algorithm aims to provide all requested services within their deadlines. When all services can not be provided on time, decision rules apply.

4. GLOBAL SCHEDULING POLICY The main objective of the global scheduler is to produce a task execution plan that minimizes the number of temporal faults. The idea is to have a very simple but efficient global policy, with no particular case. All specific or particular demands are handled 10caIly by AAOs.

3.1. Decision rules An optimal solution can be easily found in dynamic scheduling when the system is not overloaded,

M=age queue

EDF (Earliest Deadline First, Liu and Layland, 1973) has been chosen as the global scheduling policy due to its optimality when the system is under loaded, and its simplicity (the task with the closest deadline runs frrst). Its main drawback is its nondeterminist behavior in case of overload, i.e., the tasks that will miss their deadlines are unknown. Nevertheless, to deal with this problem the importance criterion was introduced: in case of overload, less important tasks are cancelled. Although the use of EDF may have many advantages (Halang and Stoyenko, 1991), any other scheduling policy would be also possible.

r : - - - - Newmessage

I

t

I

=-"'r x/ill-=:

:WT61.! r ii~ .•

Waiting and Running methocb :

~

I ..

Figure 2. Messages filtering.

145

Alarms. Alarms signal events such as task

4.1. Decision information

deadline missed or assigned cpu time consumed. Metaobjects receive alarms and forward them to the scheduler. Since a metaobject knows its message faults, it can take appropriate decisions.

Task. In the context of this article, a task is a thread

linked to a message that conveys the following data: Task Deadline. Task Importance (low, nonnal, high, guarantee, emergency). For a guarantee task, the server notifies immediately the client about the acceptance of the task. An emergency task is executed immediately. A low task doesn't have time constraints and is executed in background. A set of methods mj, and for eaeh-one its worst and best case execution time (WCET, BCET).

5. LOCAL DECISION Each AAO adopts a specific policy according to its objectives. Metaobjects make local decisions to choose the messages to schedule, and to define a method set for each message. A metaobject can not schedule all the messages when it doesn't have enough threads, but its knowledge of the global scheduling policy allows it to select the messages with the best chance to be selected at global level.

Scheduling The scheduler maintains two task lists,

one for the schedulable tasks sorted by increasing deadline, and another for currently non schedulable tasks. As a method execution may complete before its declared WCET, tasks from the latter list may become schedulable and be moved to the former list.

5.1. Local scheduling As every metaobject policy is specific, only some general criteria are described.

4.2. Scheduler main activities

The scheduler performs two main activities, triggered by events such as arrival and end of tasks, and alarms like deadline and expected end of task. First, it selects the task to execute, according to EDF. Second, when a task is started for the first time, the scheduler chooses from the task methods set, the highest quality method able to be completed within the available time. This choice is made as late as possible in order to get the best quality while still respecting constraints. Once started, the chosen method for a task doesn't change.

Schedulability. Before to schedule any message, the metaobject may verify if the fastest method of the method set fits in the scheduling. Guarantee. In principle, an object asking for a guarantee should have a fallback option in case of refusal. A refusal only means that the task may miss its deadline, since it is based on the declared WCET. The request can be kept without guarantee, waiting for the last moment to execute an alternative action. Importance and deadline. If a message m calls m' and waits for the reply, the importance of m' should be at least equals to the m's one and the deadline of m' should be strictly less than the m's one (required in distributed applications). These constraints enforce precedence rules since EDF ensures that m' will be executed before m. If no reply is waited, importance and deadline can be chosen independently.

Task arrival. When a task arrives, the scheduler

tries to schedule it, considering the WCET of its smallest duration method. If the task is schedulable, it is placed in the sorted list of scheduled tasks. If the new task becomes the first ready task of the list, the task in progress is preempted, and the new task execution starts. If the task is not schedulable, the scheduler searches for less important tasks that can release cpu time for the new task. If enough time is freed by removing less important tasks, the scheduler moves them to the non schedulable tasks list and puts the new task in the planning. If the task importance is guarantee, the scheduler notifies immediately the client about the guaranty of its deadline respect. When the task importance is emergency, the task is executed before all lower importance tasks, whatever the deadlines. Task end. The ending task is removed from the planning and, if previously engaged time becomes available (actual execution time smaller than WCET), the scheduler tries to schedule tasks from the non schedulable tasks list. Finally, the first ready task is started.

Delegation. A metaobject may redirect a received

request to another (generally distant) object capable of providing the requested service. Specially useful when the system is overloaded. Availability Messages to be served after a certain

date, stay in the queue and are analyzed when the date is reached. Periodic messages. Periodicity is defined by the

client. The message stays in the queue until the client removes it. At the beginning of every period, the rnetaobject treats the message is any other one.

146

5.2. Mechanisms to avoid/aults - . - 1meth

This section gives an outline of the mechanisms retained to avoid temporal faults. Some of them are: - Polymorphism. Several methods provide the same service with different duration (WCET) and service quality (Time polymorphic invocation in Takashio and Tokoro, 1992; Garvey and Lesser, 1993). According to the available cpu time, the method with the best possible quality is executed. - Task-pair. This policy needs two tasks (Streinch, 1995): a main task with known optimistic duration (OCET m) and an exception one with known worst case duration (WCET.,). The main task is started and if it has not finished at the last date for the exception task to meet its deadline, it is stopped and the exception task is executed. - Decision rules. Instead of requiring the execution of a message in the same way every time, some flexibility is given to the server through decision rules (Delacroix, 1996). For instance "The message x can be executed one time out of two", or "The deadline of the message x must not be missed more than three consecutive times". This flexibility is to be used to reduce temporal faults.

20

.••. ·2meth

15 ~=+_==3m=.=lh=F-_----:,...:I>:"/+ ,

,.

,.

--j

/ /

/

.. .. •u:...:.-.Afll-~"'-""=-E-·':!:l:"'~~:"-'-" .. ~ >--;= ,-

~

...'._._ ..

70

eo

90

100

110

__

120

130

Lo.~4&

Figure 3. Polymorphism effect on faults.

5.4. Predictability As task arrival dates are unknown, predictability is not possible. However, a static worst case temp~ral analysis should be made to assure correct execution of emergency messages. Nevertheless, to reduce uncertainty, an AAO may request a guarantee, to know immediately if there is a scheduling problem.

6. RESULTS

6.1. Simulation

5.3. Method Set composition

A simulation model was developed to evaluate the proposed ideas. Experiments were made with Pois~on random arrivals dates and EDF as local policy. Uniformly distributed random values were used for method's WCET, actual execution times and deadlines. The global scheduler applies an enhanced EDF policy with preemption. In case of overload, less important tasks are cancel1ed.

Several policies to build method sets may be applied. An AAO may actual1y own several methods to provide the same service, but more artificial sets can be built to achieve particular goals.

Filters and methods. Each message is associated to a set of methods which provide the requested service. As methods have different characteristics, those that don't pass filters are removed. Examples of set are: - Set of methods of different duration and quality. - Set of methods requiring different resources or holding different concurrency or state constraints. - Set implementing decision rules. Many rules are possible according to the object's state, running methods, etc. For example the rule "execute m/ at least I time out of 2", can be implemented by a set having the method mJ and a Null method (WCET=O). If the Null method is chosen at global level in one request, then in the next request the set of wil1 have m J only. - Task-Pair. In this mechanism, two messages are used: the main and the exception ones. A solution is to schedule both messages, giving a closer deadline to the main one and a greater importance to the exception one. The exception method wil1 start at the latest possible date, even if the main method has not finished, because of its greater importance. If the main method completes, the exception message is removed from the schedule.

Set of methods (polymorphism). Fig. 3 shows how polymorphism decreases the number of faults (sets with I, 2 and 3 methods, with duration WCET, WCET/2 and WCET/3, respectively). For a load of 95%, faults decrease from about 7% for I method down to I% for 2 methods and 0.5% for 3 methods. Number of threads per AAO. Experiments show that, as the number of threads increases, the number of faults of more important tasks decreases while it increases for less important ones. So, graceful degradation is better achieved with more threads per AAO (Fig. 4). However, for more than 3 threads, there was no notable effect on fault reduction. In fact, the difference of total faults between 3 and 20 threads per AAO, was less than I% (Fig. 5).

6.2. Prototype (MO overhead) A prototype of the AAO with message passing, filters, threads, and scheduling, was developed and tested under Windows NT (p1I, 233Mhz).

147

# 11

• • • • ·1th Low Imp

"'"

~ 20ths

Low Imp

0

C1

.e·

~M ,e' "

5 4

o

cd ,

70

~

80

o'

I·..·•··• 100

0

.

110

_

~20ths

.

l~Load

/'

,

Low Imp

('{.

E

V

6

~

5 4

120

/-

----Q--20ths High Imp

9

8 7

;/

-:- ~

J..

. ' .k 90

,

10

.k

.•

3 2 1

..

/'

---o--2Oths High Im

ve • • • - -3ths Low Imp

16 -_ u. - • • - -3ths High Imp 11 -

/

. . . . . ·1th High Imp

u. 11 10 9 8 7 6

# 11

/

_ • .IL' ~

.:A

0

%

70

Figure 4. Thread effect on degradation.

80

90

100

110

120

l:Load %

Figure 5. Thread effect on faults. The proposed model also enforces the respect of 00 principles and the separation of treatments of the user problem and the execution context. As consequence, program change and portability are eased. Also, as metaobjects isolate objects, they are not perturbed by the incorporation or removal of other objects into the system. During execution, clients can deal with better local decisions by using mechanisms such as guarantees and questions to servers ("what is the execution time of method m?"). Although AAOs include known techniques to avoid faults, the originality lies in the way they are mixed and selected by metaobjects.

Experiments of messages between AAOs, showed that, all tasks being schedulable, metaobject time is: 1031ls (Null method) and 160llS (Null method with reply). Obviously, overheads appear, but their cost is low, considering the gain on services and flexibility provided by the metaobject.

7. RELATED WORKS Reflective architectures in RT have appeared in works such as (Honda and Tokoro, 1992), the ABCL language (Matsuoka, et aI., 1991), Spring (Stankovic and Ramamritham, 1993) and Apertos (Yokote and Building, 1992). In all of them, the ability to share resources and to control objects is a key point for architectural aspects. In (Honda and Tokoro, 1992) each object owns a standard metaobject and a RT metaobject with a common scheduler. In (Matsuoka, et aI., 1991) metaobjects belong to a group where all of them share the same scheduler. The approach proposed for AAOs, offers decision capabilities at metaobject level, leading to a more decentralized architecture, with highly autonomous objects. In (Deng and Liu, 1997), the architecture also has two levels, but all tasks of a server are known to be schedulable on a less powerful virtual processor. So, the problem to solve is different.

In future works, standard policies at metaobject level will be deeply studied. For a better control of object activity times an implementation in a RTOS is to be done. The use of a distributed platform to test the AAO adaptability capabilities is also considered.

9. REFERENCES Chiba S., Masuda T., "Designing an Extensible Distributed Language with a Meta-Level Architecture", ECDDP, LNCS 707, 1993, pp.482-501 Contreras, J.L. Sourrouille J.L., "Adaptive Active Objects", ECDDP, Springer Verlag, LNCS 1543, 1998, pp.369-371. Delacroix J., "Towards a stable Earliest Deadline scheduling algorithm", Real-Time Systems Journal, VoIIO(3), 1996, pp.263-291. Deng Z., Liu J. W.-S., "Scheduling real-time applications in an open environment". RTSS, IEEE,1997,pp.308-319 Garvey A., Lesser V., "Design-to-time Real-Time Scheduling", IEEE Trans. Systems, Man and Cybernetics (Issue on Planning, Scheduling and Control), Vo1.23(6), 1993, pp.1491-1502 Halang W.A., Stoyenko A.D., Constructing Predictable Real Time Systems, Kluwer Academic Publishers, 1991. Honda Y, Tokoro M., "Soft Real-Time Programming through Reflection", IMSA Workshop Reflection and Meta-Ievel Achitecture, 1992 Leung J.Y, "Research in Real-Time Scheduling", in Foundations of Real-Time Computing-Scheduling

In relation to faults avoiding, the AAOs basis for adaptability, scheduling flexibility and fault tolerance are close to Spring (Stankovic and Rarnamritham, 1993) and to "design-to-time scheduling" (Garvey and Lesser, 1993). Nevertheless, the proposed solution differs due to the metaobject based architecture that allows each AAO to have its own scheduling policy.

8. CONCLUSION This work shows a way to preserve object autonomy while keeping the advantages of centralized scheduling. At metaobject level, method sets and decision rules increase global scheduler possibilities while ensuring true guarantees to clients.

148

and Resource management, Kluwer Academic Publishers, 1991, pp.31-62 Liu CoL. , 1.W. Layland, "Scheduling algorithms for multiprogramming in a hard real time environment", Journal of the ACM, Vol 20(1), 1973, pp.46-61. Maes Po, "Concepts and experiments in Computational Reflection", OOPSLA, 1987, pp.147-155 Matsuoka S., Watanabe B., Yonezawa A., "Hybrid Group Reflective Architecture for 000. Concurrent Reflective Programming", Proc. ECOOP, Springer Verlag LNCS 512,1991, pp.23 1-250 Smith Bo, "Reflection and Semantics in a Procedural Language", MIT, TR 272,1982 Stankovic 1., Ramamritham K., "A Reflective Architecture for Real-Time Operating Systems", in Advances in Real-Time Systems, Prentice Hall, 1993, pp.23-38 Stankovic 1., et aI., "Implications of Classical Scheduling Results for Real-Time Systems", IEEE Computer, Vol. 28(6), 1995, pp. 16-25. Streinch H., "Task Pair Scheduling: an Approach for Dynamic Real-Time Sytems", Journal of Mini&Microcomputers, 17(2), 1995, ppo77-83 Takashio K., M. Tokoro, "DROL: an object-oriented programming language for distributed real-time systems", OOPSLA, ACM Sigplan, 1992, pp.276294 Yokote Y., Building T., "The Apertos Reflective Operating System: The Concept and its Implementation", OOPSLA, 1992, pp.414-434

149