Global Scheduling of Multi-Mode Real-Time Applications upon Multiprocessor Platforms

02/10/2011 ∙ by Vincent Nélis, et al. ∙ 0

Multi-mode real-time systems are those which support applications with different modes of operation, where each mode is characterized by a specific set of tasks. At run-time, such systems can, at any time, be requested to switch from its current operating mode to another mode (called "new mode") by replacing the current set of tasks with that of the new-mode. Thereby, ensuring that all the timing requirements are met not only requires that a schedulability test is performed on the tasks of each mode but also that (i) a protocol for transitioning from one mode to another is specified and (ii) a schedulability test for each transition is performed. We propose two distinct protocols that manage the mode transitions upon uniform and identical multiprocessor platforms at run-time, each specific to distinct task requirements. For each protocol, we formally establish schedulability analyses that indicate beforehand whether all the timing requirements will be met during any mode transition of the system. This is performed assuming both Fixed-Task-Priority and Fixed-Job-Priority schedulers.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 33

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Hard real-time systems require both functionally correct executions and results that are produced on time. Control of the traffic (ground or air), control of engines, control of chemical and nuclear power plants are just some examples of such systems. Currently, numerous techniques exist that enable engineers to design real-time systems while guaranteeing that all the temporal requirements are met. These techniques generally model each functionality of the application by a recurrent task, characterized by a computing requirement, a temporal deadline and an activation rate. Commonly, real-time applications are simply modeled by a single and finite set of such tasks. However, practical applications often exhibit multiple behaviors issued from several operating modes (e.g., an initialization mode, an emergency mode, a fault recovery mode, etc.), where each mode is characterized by its own set of functionalities, i.e., its set of tasks. During the execution of such multi-mode real-time applications, switching from the current mode (called the old-mode) to any other mode (called the new-mode) requires to substitute the currently executing task set with the set of tasks of the new-mode. This substitution introduces a transient phase, where tasks of both the old- and new-mode may be scheduled simultaneously, thereby leading to a possible overload that can compromise the system schedulability—indeed it can be the case that both the old- and new-mode have been asserted schedulable by the schedulability analysis but the transition between them fails at run-time.

The scheduling problem during a transition between two modes has multiple aspects, depending on the behavior and requirements of the old- and new-mode tasks when a mode change is initiated. Upon a mode change request:

  • an old-mode task may be allowed to be immediately aborted or, on the contrary, can be required to complete the execution of its current active job (so that it preserves data consistency for instance). Using scheduling algorithms such as the one considered in this study, we will prove in Section 5 that aborting tasks upon a mode change request does not jeopardize the schedulability of the mode transitions. Hence, we assume in this paper the most problematic scenario in which every old-mode task must complete its current active job (if any) when a mode change is requested.

  • a new-mode task either requires to be activated as soon as possible when a mode change is requested or requires to be activated only when all the active jobs issued from the old-mode have totally completed their execution.

Finally, there may be some tasks (called mode-independent tasks in the literature) that belong to more than one mode and such that their activation pattern must not be jeopardized during the transition between those modes111In practice, mode-independent tasks typically allow to model daemon functionalities.. However this paper will consider only systems that do not include such tasks.

Transition scheduling protocols for tasks without mode-independent tasks are often classified with respect to the way they schedule the old- and new-mode tasks during the transitions. In the literature (see for instance 

[JoAlfons:04] which considers uniprocessor systems), the following definitions are used.

Definition 1 (Synchronous/asynchronous protocol [JoAlfons:04])

A transition protocol is said to be synchronous if it schedules new-mode tasks only when all the old-mode tasks have completed. Otherwise, it is said to be asynchronous.

Definition 2 (Protocol with/without periodicity [JoAlfons:04])

A transition protocol is said to be “with periodicity” if and only if it is able to deal with mode-independent tasks. Otherwise, it is said to be “without periodicity”.

1.1 Related work

Numerous transition protocols have been proposed for uniprocessor platforms (a survey about this concern is presented in [JoAlfons:04]). In such environments, existing researches [JoAlfons:04, Henia:07, Pedro:98] have shown that even if two modes of the application have been proven feasible, the transition between the two modes can cause violation of timing constraints, hence needing explicit analyses. Such analyses have been proposed in [Sha:89], considering the popular Rate Monotonic Algorithm. Unfortunately three years later, this analysis was shown optimistic [Tindell:92] in the sense that some unfeasible task sets could be asserted schedulable. In the same paper [Tindell:92], the authors improved the previous analysis and proposed a new one which considers the popular Deadline Monotonic Algorithm. An analysis of sporadic tasks scheduled on EDF is known as well [Andersson:08]. In [Stoimenov:09], the authors proposed an analysis which considers Fixed-Task-Priority scheduling (FTP), Earliest-Deadline-First [Liu:73] scheduling and arbitrary task activation pattern. Furthermore, for applications that were initially proven not schedulable during the transition phases, they derived the required offsets for delaying the initialization of transition between two modes in order to make the application schedulable.
Among the uniprocessor synchronous protocols, the authors of [Bailey:93, Tindell:96, JoAlfons:04] proposed the following protocols.

  • The Minimum Single Offset Protocol (MSO) [JoAlfons:04] where the last activation of each old-mode task completes and then, the new-mode tasks are released.

  • The Idle Time Protocol (IT) [Tindell:96] where the periodic activations of the old-mode tasks are suspended at the first idle time-instant occurring during the transition and then, the new-mode tasks are released.

  • The Maximum-Period Offset Protocol (MPO) [Bailey:93] where the delays of first activation of each new-mode task is equal to the period of the less frequent task in both modes,

Among the uniprocessor asynchronous protocols, the authors of [Tindell:92, Pedro:99, Andersson:08] proposed the following protocols.

  • A protocol without periodicity [Pedro:99] where tasks are assigned priorities according to the Deadline Monotonic Scheduling algorithm and are scheduled with time offsets during the mode change only.

  • A protocol with periodicity has been introduced by Sha et al. in [Sha:88], assuming Fixed-Task-Priority scheduling. Then, the authors of [Andersson:08] extended this protocol to the Earliest Deadline First [Liu:73] scheduling algorithm.

  • The authors of [Tindell:92] introduced a particular protocol which allows tasks to modify their parameters (period, execution time, etc.) during the mode changes. As in [Pedro:99], this study assumes that the tasks are scheduled according to the Deadline Monotonic scheduling algorithm.

1.2 Contribution and paper organization

In this paper we propose two protocols without periodicity ( which is synchronous and which is asynchronous) for managing mode transitions during the execution of multi-mode real-time applications on multiprocessor platforms. Both protocols can be considered as a generalization to multiprocessors of the MSO protocol proposed in [JoAlfons:04]. We assume that every operating mode of the application is scheduled by a global, work-conserving, preemptive and Fixed-Job-Priority (FJP) scheduling algorithm (formal definitions are given in Section 2.4). Some of the results presented here have already been published (see [MeumeuNelisGoossens:10, NelisAnderssonGoossens:09, NelisGoossensAndersson:09, NelisGoossens:08]). It is worth noticing that the problem of scheduling multi-mode applications upon multiprocessor platforms is much more complex than upon uniprocessor platforms, especially due to the presence of scheduling anomalies (see Chapter 5 of [Andersson:03] for a definition) and it is now well known that real-time multiprocessor scheduling problems are typically not solved by applying straightforward extensions of techniques used for solving similar uniprocessor problems.

The paper is organized as follows. Section 2 defines the computational model used throughout the paper. Sections 3 and 4 describe the synchronous and asynchronous protocols and , respectively. Section 5 introduces some definitions and basic results necessary for the establishment of our schedulability analyses. These four first Sections 25 are a common base of the paper, in the sense that these 6 pages describe both the models of computation and protocols independently of the platform and scheduler characteristics. Then, the four next Sections 69 are each specific to a platform and scheduler model. More precisely, they provide a schedulability analysis for both and , assuming in turn identical platforms and Fixed-Job-Priority schedulers (in Section 6), identical platforms and Fixed-Task-Priority schedulers (in Section 7), uniform platforms and Fixed-Job-Priority schedulers (in Section 8) and uniform platforms and Fixed-Task-Priority schedulers (in Section 9)222Even though Fixed-Job-Priority schedulers encompass the family of Fixed-Task-Priority schedulers, the particular case of Fixed-Task-Priority schedulers is treated separately so that the schedulability analyses are more specific and therefore more accurate.. Finally, Section 10 gives our conclusions and future work, together with some remaining open problems.

2 Models of computation and specifications

2.1 Application specifications

We define a multi-mode real-time application as a set of operating modes denoted by where each mode has to execute its associated task set composed of tasks by following the scheduler . At run-time, the application is either running in one and only one mode, i.e., it is executing only the set of tasks associated to that mode, or it is switching from one mode to another one. Since we do not consider mode-independent tasks in this study, it holds that .

Each task is modeled by a sporadic and constrained-deadline task characterized by three parameters —a worst-case execution time , a minimum inter-arrival time and a relative deadline —with the interpretation that, during the execution in mode , task generates successive jobs (with ) released at times such that (with ), each such job has an execution requirement of at most , and must be completed at (or before) its absolute deadline noted . In the particular case where , the task is said to be periodic instead of sporadic. In the same vein, if then the task is said to be implicit-deadline instead of constrained-deadline.

Definition 3 (Active job)

We say that a job is active at time if it has been already released (i.e., ) and it is not completed yet.

Since we assume , there cannot be two jobs of a same task active at a same time in any feasible schedule. All the tasks are assumed to be independent, i.e., there is no communication, no precedence constraint and no shared resource (except the processors) between them. In [NelisGoossensAndersson:09], we introduced the following concept of enabled/disabled tasks.

Definition 4 (Enabled/disabled tasks [NelisGoossensAndersson:09])

At run-time, any task of the application can generate jobs if and only if is enabled. Symmetrically, a disabled task cannot generate jobs.

As such, disabling a task prevents future job releases from . When all the tasks of any mode are enabled and all the tasks of all the other modes are disabled, the application is said to be running in mode (since only the tasks of mode can release jobs). We denote by and the subsets of enabled and disabled tasks of at time , respectively.

2.2 Platform specifications

Many recent embedded systems are built upon multiprocessor platforms in order to fulfill the high computational requirements of applications. As pointed out in [Baruah:03, Baruah:04], another advantage of such a choice is the fact that multiprocessor systems are more energy efficient than equally powerful uniprocessor platforms. Indeed, raising the frequency of a single results in a multiplicative increase of the consumption while adding s results in an additive increase. Two distinct multiprocessor architectures are commonly used in the industrial world and thus, are considered in this paper: identical and uniform platforms.

Identical platform. In such multiprocessor platforms, all the s have the same computational capabilities, with the interpretation that in any interval of time two s execute the same amount of work (assuming that none of them is idling). In the remainder of this paper, any platform composed of identical s will be modeled by where denotes the of the platform.

Uniform platform. In such multiprocessor platforms, the s are allowed to have different computational capabilities. That is, a parameter is associated to every with the interpretation that in any time interval of length , executes units of execution (if it is not idling). This parameter can be seen as the execution speed of the . In the remainder of this paper, any platform composed of uniform s is modeled by , where is the execution speed of . Without loss of generality, we assume that , meaning that is the fastest while is the slowest one. For all , we denote by the cumulated speed of the fastest s, i.e.,

(1)

Notice that identical platforms are a particular case of uniform platforms where . In this particular case we assume without any loss of generality that : .

2.3 Mode transition specifications

While the application is running in any mode , a mode change can be initiated by any task of or by the system itself, whenever it detects a change in the environment or in its internal state for instance. This is performed by invoking a (i.e., a Mode Change Request), where is the destination mode. We denote by the invoking time of the last . From the time at which a mode change is requested to the time at which the transition phase ends, and are referred to as the old- and new-mode, respectively.

At run-time, mode transitions are managed as follows. Suppose that the application is running in mode and the system (or any task of ) comes to request a mode change to mode , with . At time , the system entrusts the scheduling decisions to a transition protocol which immediately disables all the old-mode tasks, thus preventing them from releasing new jobs. At this time, the active jobs issued from these disabled tasks, henceforth called the rem-jobs (for “remaining jobs”), may have two distinct behaviors: either they can be aborted upon the or they can complete their execution. From the schedulability point of view, we will show that aborting some (or all) rem-jobs upon a mode change request does not jeopardize the system schedulability during the transition phase. Consequently, we assume the worst-case scenario for every mode transition, i.e., the scenario in which every old-mode task has to complete its last released job (if any) during every mode transition333Aborting a job consists in suddenly stopping its execution and removing it from the system memory. But in the real world, suddenly killing a process may cause system failures and the rem-jobs often have to complete their execution.. The fact that the rem-jobs have to complete their execution upon the brings the following problem. Even if both task sets and (from the old- and new-mode, respectively) have been asserted to be schedulable upon the s at system design-time, the presence of the rem-jobs may cause an overload during the transition phase (at run-time) if all the new-mode tasks of are enabled immediately upon the mode change request. Indeed, the schedulability analysis performed beforehand on did not take into account the additional work generated by the rem-jobs. To solve this problem, transition protocols usually delay the enablement of each new-mode task until it is safe to do so. However, these delays are also subject to hard constraints. More precisely, we denote by the relative transition deadline of task during every transition from mode to mode , with the following interpretation: the transition protocol must ensure that is enabled not later than time . Finally, when all the rem-jobs are completed and all the new-mode tasks of are enabled, the system entrusts the scheduling decisions to the scheduler of the new-mode and the transition phase ends.

In short, the goal of any transition protocol is to fulfill the following requirements during every mode change:

  1. Complete each rem-job by its absolute deadline .

  2. Enable each new-mode task by its absolute transition deadline .

  3. Complete each new-mode job444This requirement is automatically fulfilled for synchronous protocols since no new-mode jobs are scheduled during the mode transitions. by its absolute deadline .

Definition 5 (Valid protocol [NelisGoossensAndersson:09])

A transition protocol is said to be valid for a given application and platform if and only if meets all the job and transition deadlines during every transition between every pair of operating modes of .

This notion of “valid protocol” is directly related to that of a “validity test” defined as follows.

Definition 6 (Validity test [NelisGoossensAndersson:09])

For a given transition protocol , a validity test is a condition based on the tasks and platform characteristics that indicates a priori whether is valid for a given application and platform .

2.4 Scheduler specifications

We consider the global preemptive scheduling problem of sporadic constrained-deadline tasks upon multiprocessor platforms. “Global” schedulers, in contrast to partitioned ones, allow different tasks and different jobs of the same task to be executed upon different s. When preemptive, global schedulers allow any job to be interrupted at any time prior to completion on any and resumed (possibly later) on any other . We consider that every mode uses its own scheduler denoted by which can be either Fixed-Task-Priority (FTP) or Fixed-Job-Priority (FJP) according to the following interpretations.

  • FTP schedulers assign a priority to each task at system design-time (i.e., before the execution of the application) and then at run-time, every released job uses the priority of its task and the priority of a job is kept constant until it completes.

  • FJP schedulers assign a priority to each job at run-time (i.e., as soon as it arrives in the system) and every job keeps its priority constant until it completes. As such, different jobs issued from the same task may have different priorities555According to these interpretations, FTP schedulers are a particular case of FJP schedulers in which all the jobs issued from a same task receive the same priority determined beforehand..

Without loss of generality we assume that, at any time, two active jobs cannot have the same priority. Furthermore, we consider work-conserving schedulers according to the following definition.

Definition 7 (Work-conserving global scheduler)

A cannot be idle if there is a job awaiting execution. Usually, priority-based schedulers assign at each instant in time the highest priority active jobs (if any) to the s.

The above definition of work-conserving schedulers encompasses a large family of schedulers, but suffers from an important lack of determinism. Indeed for a given set of jobs, multiple (and different) schedules can sometimes be derived from the same work-conserving scheduler (and thus from the same job priority assignment). The following example illustrates this drawback.

Example 1

Let us consider the set of jobs with respective processing time 4, 8, 4, 4 and 6. Suppose that is scheduled on a -processors identical platform by an FTP, global, preemptive and work-conserving scheduler such that . According to Definition 7, Figures 1 and 2 depict two possible different schedules corresponding to this priority assignment.

Figure 1: A possible schedule of and .
Figure 2: Another possible schedule of and .

In order to get around this lack of determinism, we introduce two refinements of Definition 7 that we name weakly and strongly work-conserving schedulers, respectively. Weakly work-conserving schedulers concern only identical platforms whereas strongly work-conserving schedulers concern only in uniform (and non-identical) platforms. The rationale for introducing these two refinements is to have one and only one possible schedule for any given set of synchronous666The term “synchronous” jobs is commonly used in the literature to refer to jobs that are all ready for execution at the same time. jobs, multiprocessor platform and job priority assignment.

Definition 8 (Weakly work-conserving scheduler)

A scheduler is weakly work-conserving if and only if:

  • no idles while there are active jobs awaiting execution, and

  • if there are more than one job awaiting execution and more than one CPU available for the execution of those jobs then S assigns the highest priority waiting job to the available with the highest index.

Property 1 (Unique schedule)

For any given finite set of jobs, any weakly work-conserving scheduler and any identical multiprocessor platform , there exists one and only one possible schedule of upon following .

In order to illustrate this property, let us consider the set of jobs used in Example 1, a 2-processors identical platform and any weakly work-conserving scheduler assigning priorities such that . The unique possible schedule of upon is the one depicted in Figure 1. Indeed at time , s and are idle and the second condition of Definition 8 imposes to execute on . From the same rule, must execute on at time . Notice that the refinement of “weakly” work-conserving scheduler clarifies only the job-to- assignment rule when the highest-priority waiting job has to be dispatched to a .

Definition 9 (Strongly work-conserving scheduler)

A scheduler is strongly work-conserving if and only if:

  • no idles while there are active jobs awaiting execution, and

  • at every time during the system execution, the job-to- assignment uses the rule: highest priority active job upon highest indexed .

In contrast to the refinement of “weakly” work-conserving schedulers, the “strongly”-refinement clarifies the job-to- assignment rule at each time-instant during the system execution. It is essential to keep in mind that in our study weakly work-conserving schedulers will be used only on identical platforms whereas strongly work-conserving schedulers will be used only on uniform and non-identical platforms. For strongly work-conserving schedulers, the concept of migrating jobs to faster s as soon as possible (as specified by the second condition of Definition 9) has been widely used over the years on uniform platforms (see [BaruahGoossens:08:2, BaruahGoossens:03, GoossensFunkBaruah:02, BaruahGoossens:08, CucuGoossens:10, FunkGoossensBaruah:01]). This refinement is extremely important, especially because it yields the following property.

Property 2 (Staircase property)

Let denote any finite set of synchronous jobs, any uniform multiprocessor platform and any strongly work-conserving scheduler. In the schedule of upon by , idles before or at the same time-instant as for all .

Informally speaking, the schedule of upon by forms a staircase (see Figure 3).

Figure 3: For any fixed set of jobs and uniform platform, the schedule generated by any strongly work-conserving scheduler forms a staircase.

This property stems from the fact that the s are indexed in such a manner that . Thus, it holds from the second condition of Definition 9 that at any instant , if idles the -slowest then also idles the slowest s for all . Also, it results from the same condition that the that starts idling is always .

The following definition introduces the fundamental notion of predictability, and Lemmas 1 and 2 are essential for the rest of the paper.

Definition 10 (Predictability [HaLiu:94])

Let denote a scheduler, and let be a potentially infinite set of jobs, where each job is characterized by an arrival time , a computing requirement and an absolute deadline . Let and denote the time at which job starts and completes its execution (respectively) when is scheduled by . Now, consider any set of jobs obtained from as follows. Job has an arrival time , an execution requirement , and a deadline . Let and denote the time at which job starts and completes its execution (respectively) when is scheduled by . Algorithm is said to be predictable if and only if for any set of jobs and for any such obtained from , it is the case that and .

Informally speaking, Definition 10 claims that an upper-bound on the starting time and on the completion time of each job can be determined by analyzing the situation under the assumption that each job executes for its WCET. The result from [Ha:95, HaLiu:94, HaLiu:93] that we will be using can be stated as follows.

Lemma 1 (See [Ha:95, HaLiu:94, HaLiu:93])

On identical multiprocessor platforms, any FJP, global, preemptive and weakly work-conserving scheduler is predictable.

In the same vein, the result from [CucuGoossens:10] that we will be using can be stated as follows.

Lemma 2 (See [CucuGoossens:10])

On uniform multiprocessor platforms, any FJP, global, preemptive and strongly work-conserving scheduler is predictable.

We use the notation to refer to a specific job priority assignment. A job priority assignment can be seen as a key component of any scheduler, but the definition of a scheduler is more general since, in addition to a job priority assignment, a scheduler must also provide specifications like “global or partitioned”, “preemptive or non-preemptive”, etc. For any job priority assignment , we denote by the fact that job has a higher priority than according to , and we assume that every assigned priority is distinct from the others. That is, such that we have either xor . Similarly, and without any distinction with the interpretation given above, we will sometimes use the notations and where is the scheduler of mode , and we will sometimes use the notations and when the job priority assignment has no label (for instance, when we will depict some examples of schedules, we will just say “” without giving a name to the job priority assignment). Finally, the problems and solutions presented in this paper are addressed under the following assumptions:

  • Assumption 1. The set of tasks of every mode can be scheduled by on s without missing any deadline.

  • Assumption 2. Job migrations and preemptions are permitted and are carried out at no loss or penalty.

  • Assumption 3. Job parallelism is forbidden, i.e., jobs execute on at most one at any instant in time.

  • Assumption 4. For every mode it holds that , where is the number of tasks in mode .

Regarding Assumption 1, it allows us to focus only on the schedulability of the application during the transient phases corresponding to mode transitions, rather than on the schedulability of the application during the execution in a given mode.

Regarding Assumption 4, it is worth noticing that since job parallelism is forbidden and tasks are assumed to be constrained-deadline, there are at most jobs active at a same time during the execution of any mode . As a result, it holds for each mode that in every schedulable application where , there are always s that constantly idle. We will see later that these idling s are the slowest ones and the problem in that case thereby reduces to the same problem upon the subset of the fastest s among these s.

3 The synchronous protocol SM-MSO

3.1 Description of the protocol

The protocol (which stands for “Synchronous Multiprocessor Minimum Single Offset” protocol) is an extension to multiprocessor platforms of the protocol defined in [JoAlfons:04] for uniprocessor platforms. This protocol supports both uniform and identical platforms. The main idea of is the following: upon a MCR(), , all the tasks of the old-mode (say ) are disabled and the rem-jobs continue to be scheduled by the old-mode scheduler upon the s. Once all the rem-jobs are completed, all the new-mode tasks (i.e., the tasks of ) are simultaneously enabled. Algorithm 4 gives the pseudo-code of this protocol and Example 2 illustrates how handles the mode transitions.

0:  : the old mode 0:  : the new-mode 0:  the rem-jobs 1:  while true do 2:     Schedule the rem-jobs according to 3:     if (any rem-job completes at time then 4:        if (then 5:           enable all the new-mode tasks of 6:           enter the new-mode 7:        end if 8:     end if 9:  end while
Figure 4: protocol
Example 2

Let us consider a platform composed of only 2 identical s and an application composed of 2 modes and depicted in blue and red, respectively. We assume that these two modes contain only synchronous implicit-deadline periodic tasks. The old-mode contains 4 tasks with characteristics given in Table 1 and uses an FTP scheduler such that .

Tasks
40 120
20 120
40 120
60 120
Table 1: Characteristics of the tasks in .

The new-mode contains 3 tasks and uses an FTP scheduler such that . The characteristics of these tasks are: and . The deadline and period of these new-mode tasks do not have any importance in this example and we intentionally omitted to specify them. Figure 5 illustrates the transition protocol between these two modes.

Figure 5: Illustration of a mode transition handled by .

At time 120, every task of releases its second job and the scheduler starts the execution of and on and , respectively. Then, suppose that the system requests a mode change at time 130. Here starts the transition phase from mode to mode . As specified by the protocol , all the old-mode tasks are immediately disabled and the remaining active jobs and (named the rem-jobs from this point forward) continue to be scheduled according to the old-mode scheduler . These rem-jobs execute until time 220, time at which they are all completed. At this instant 220, the condition at line 4 of Algorithm 4 is verified. Thus, enables all the new-mode tasks and starts scheduling the incoming new-mode jobs according to the new-mode scheduler . Notice that at any time during every transition phase, our protocol allows the system (or any task) to request any other mode change. At the very end of the current transition phase (at time 220 in this example), enables all the tasks of the mode assuming that is the last mode change that has been requested.

3.2 Design of a validity test

In order to establish a validity test for the protocol , two key results are required:

  1. It must be proved for every mode transition that disabling the old-mode tasks upon a MCR does not jeopardize the schedulability of the rem-jobs when they continue to be scheduled by the old-mode scheduler. That is, it must be guaranteed that the absolute deadline of every rem-job is met during every mode transition from every mode .

  2. It must be proved for every mode transition that the length of the transition phase can never be larger than the minimum transition deadline of all new-mode tasks. Indeed, it follows from this statement and the definition of that all the transition deadlines would be met during every mode transition.

We provided a proof for the first key result in [NelisGoossensAndersson:09] (the proof is replicated in Section 5, page 4), and this result holds for any uniform platform (including identical platforms). About the second key result, it is worth noticing that there is no job release (and therefore no preemption) during every transition phase since we consider only FJP schedulers and all the old-mode tasks are disabled upon any mode change request. As a consequence, the length of any transition phase corresponds to the time needed to complete all the rem-jobs (this clearly appears in Figure 5). In the literature (and hereafter as well), the time needed to complete a given set of synchronous jobs upon a given platform is called the makespan defined as follows.

Definition 11 (Makespan)

Let denote any set of jobs of processing times . Let denotes any uniform multiprocessor platform composed of s. Let denote any job priority assignment and denotes the schedule of upon by any work-conserving scheduler (including weakly and strongly work-conserving schedulers) using the priority assignment . The makespan denoted by is the earliest instant in such that the jobs of are completed.

According to Definition 11, the length of any transition phase corresponds to the makespan generated by the set of jobs that are active in the system when the mode change is requested, i.e., the set of rem-jobs. Since the value of the makespan obviously depends on the number and processing times of the jobs (as well as on the speeds), then the length of any transition phase from any mode to any other mode depends on both the number of rem-jobs and their remaining processing time at time . From this observation, determining an upper-bound on the makespan requires to consider the worst-case scenario, i.e., the scenario in which the number and the remaining processing time of the rem-jobs at time is such that the generated makespan is maximum. This worst-case scenario is thus entirely defined by a specific set of rem-jobs that we name the critical rem-job set defined as follows.

Definition 12 (Critical rem-job set )

Assuming any transition from a specific mode to any other mode , the critical rem-job set is the set of jobs issued from the tasks of that leads to the largest makespan.

For any work-conserving FJP scheduler (including FTP schedulers) and uniform platform (including identical platform), we will show that the critical rem-job set of every transition from mode to mode is the one where each task has a rem-job at time with a remaining processing time equals to (i.e., the WCET of ). This result is very intuitive: the makespan is as large as the number and processing times of the rem-jobs are large.

In this paper we address the problem of establishing mathematical expressions that provide the maximum makespan for any given set of synchronous777During every mode transition, the considered jobs are assumed to be synchronous because every rem-job is active and ready to execute upon the mode change request. jobs and especially for the critical rem-job set during each mode transition. This intention stems from the fact that the knowledge of the maximum makespan allows us to assert (or refute) that every new-mode task will meet its transition deadline during any mode transition using , thus ensuring the validity of for a given application and platform as follows.

Validity Test 1 (For protocol )

For any multi-mode real-time application and any uniform multiprocessor platform , protocol is valid provided that, for every mode ,

(2)

where is the job priority assignment derived from the old-mode scheduler and is an upper-bound on the makespan, considering the set of jobs, the platform and the job priority assignment .

The above expression can be interpreted as follows: all the transition deadlines will be met during the execution of the system if, for every mode , the maximum makespan (i.e., the maximum transition latency) generated by the rem-jobs issued from the tasks of cannot be larger than the minimum transition deadline of every task of every mode .

This validity test is a sufficient condition that indicates, a priori, if all the deadlines will be met during all possible mode changes using the protocol . Unfortunately, to the best of our knowledge, the problem of determining the maximum makespan has never been studied in the literature. Rather, authors usually address the problem of determining a job priority assignment that minimizes the makespan [Goyal:05, Garey:90]. The goal in that framework being to ultimately reduce the completion times of the jobs as much as possible. This problem of finding priorities that minimize the makespan can be cast as a strongly NP-hard bin-packing problem [Goyal:05, Garey:90]

for which numerous heuristics have been proposed in the literature. On the contrary, we provide in Sections 

69 different upper-bounds on the makespan, assuming in turn identical platforms and FJP schedulers, identical platforms and FTP schedulers, uniform platforms and FJP schedulers and finally, uniform platforms and FTP schedulers.

3.3 FTP schedulers vs. FJP schedulers

As mentioned in Section 2.4, FTP schedulers are a particular case of FJP schedulers. However the remainder of this study distinguishes between these two scheduler families because FTP schedulers allow to determining a more precise upper-bound than FJP schedulers. The reason of this stems from the fact that the priority of each task (and thus the priority of every job) is known at system design-time for FTP schedulers whereas it is unknown beforehand for FJP schedulers.

At first blush, assuming that the job priority assignment is unknown for FJP schedulers can seem inconsistent since during every mode transition, we consider the critical rem job set in the computation of (and this critical rem-job set is determined at system design-time). Therefore, it could be thought that can simply be derived from . But this intuition is erroneous because for a given FJP scheduler, several job priority assignments can be derived from the same critical rem-job set as shown in the following example. Actually, given set of jobs, we are not aware of any job priority assignment leading to the maximum makespan.

Example 3

Let us consider a platform composed of only 2 identical s and an application composed of 2 modes and . Suppose that a mode change is requested from to and the old-mode scheduler is . The old-mode contains 3 tasks with characteristics given in Table 2.

Tasks
5 15
5 16
7 18
Table 2: Characteristics of the tasks in .

As introduced earlier, the critical rem-job set for this mode transition is given by with processing time and , respectively. This will be formally proved in Corollary 1 (on page 1), assuming any FJP scheduler and any uniform platform. Actually, this critical rem-job set specifies only the processing time of the jobs, not the release time, neither the absolute deadline. Consequently, different job priority assignments can be derived from . We depict two of them in Figures 6 and 7. In both figures the time is relative to the instant (i.e., ). The release time and the absolute deadline of each job are denoted by and , respectively. These two job priority assignments are obtained as follows.

Job priority assignment 1. If we assume that the three jobs are released exactly at the invoking time , i.e., , then the absolute deadline of each job is given by . In Figure 6, the deadline of each job is thus: , and and according to , this leads to the job priority assignment (and to a makespan of ).

Figure 6: Assuming that the three jobs are released simultaneously upon the allows to derive a first job priority assignment.

Job priority assignment 2. Starting from the previous release pattern in which all the jobs are released simultaneously at time , one can slightly move backward the release time of job (for instance) in such a manner that is released at time (see Figure 7). Its absolute deadline is thus shifted to time and since no assumption is made about the schedule before time , we can suppose that did not execute before . Therefore, the processing time of at time is and the job priority assignment resulting from this new release pattern is (leading to a makespan of ).

Figure 7: Another job priority assignment can be derived by slightly modifying the release pattern of the jobs. Note that this modification leads to another makespan.

In the particular case of , shifting the absolute deadline of these three jobs by distinct amplitudes can modify their relative priorities and a possibly large number of job priority assignments can be derived from the same critical rem-job set .

Because the prior knowledge of the critical rem-job set does not allow determining a unique job priority assignment, FJP schedulers require to consider every possible job priority assignment in order to determine an upper-bound on the makespan. Hence, we refine the notation of as follows: the upper-bound on the makespan is denoted by when is explicitly specified (in the context of FTP scheduler) and by otherwise (in the context of FJP scheduler), with the interpretation that for every job priority assignment :

It goes without saying that the prior knowledge of the jobs priority assignment allows for establishing tighter upper-bounds on the makespan, i.e., the upper-bound is tighter than . From these refined notations, Expression 2 of Validity Test 1 can be rewritten as

for FJP schedulers, and as

for FTP schedulers, where is the job priority assignment derived from the old-mode FTP scheduler .

4 The asynchronous protocol AM-MSO

4.1 Description of the protocol

The protocol (which stands for “Asynchronous Multiprocessor Minimum Single Offset” protocol) is an asynchronous version of the protocol . This protocol supports both uniform and identical platforms. The main idea of this second protocol is to reduce the delay applied to the enablement of the new-mode tasks, by enabling them as soon as possible. In contrast to SM-MSO, rem-jobs and new-mode tasks can be scheduled simultaneously during the transition phases according to the scheduler defined as follows: (i) the priorities of the rem-jobs are assigned according to the old-mode scheduler; (ii) the priorities of the new-mode jobs are assigned according to the new-mode scheduler, and (iii) the priority of each rem-job is higher than the priority of every new-mode job.

Formally, suppose that the system is transitioning from mode to mode and let and be two active jobs during this transition. According to these notations we have if and only if one of the following conditions is satisfied:

or
or

proceeds as follows: upon a , , all the old-mode tasks are disabled and the rem-jobs continue to be scheduled by (assuming that is the old-mode). Whenever any rem-job completes (say at time ), if there is no more waiting rem-jobs immediately enables some new-mode tasks, in contrast to which waits for the completion of all the rem-jobs. In order to select the new-mode tasks to enable at time , uses the following heuristic: it considers every disabled new-mode task by non-decreasing order of transition deadline and enables those which can be scheduled by upon the current available CPUs, i.e., the CPUs that are not running a rem-job and are therefore available for executing some new-mode tasks. The following example illustrates how manages mode transitions.

Example 4

Let us consider the same task sets as in Example 2. Figure 8 illustrates the transition protocol on a 2-processors platform.

Figure 8: Illustration of a mode transition handled by .

Similarly to protocol , schedules the rem-jobs according to the old-mode scheduler from time to time . Then at time , the rem-job completes on and there is no more waiting rem-jobs. Here reacts differently from : it scans every disabled task of (in non-decreasing order of transition deadline) and enables some of them in such a manner that the resulting set of enabled new-mode tasks can be scheduled by upon 1 (since at this time , only the is available for executing some new-mode tasks). We actually have no guarantee that scanning all the disabled tasks in non-decreasing order of transition deadline is optimal, but this heuristic appears as the most intuitive choice. At time 220, performs the same treatment as at time . But since we assumed that every task set , , is schedulable by on , we know that all the remaining disabled new-mode tasks can be enabled at this time 220.

Notice that, in contrast to , the protocol allows mode changes to be requested during the mode transitions only until some new-mode tasks have been enabled (the instant in Figure 8). Indeed, if the system is transitioning from any mode to any other mode and a mode change is requested to any mode before time , then can consider that the system is transitioning from mode to mode and the new-mode therefore becomes the mode . However after time , some tasks of mode have already been enabled and does not allow the system to request any other mode change until the end of the transition phase from to , i.e., until all the tasks of mode are enabled.

In order to determine whether a task can be safely enabled, protocol uses a binary function that returns if and only if the task set is schedulable by upon . This function is essential as we must always guarantee that all the deadlines are met for all the jobs in the system, including the deadlines of all the new-mode jobs. Considering a specific scheduler , such a function can be derived from schedulability tests proposed for in the literature888To the best of our knowledge, there is no efficient necessary and sufficient schedulability test for any multiprocessor scheduler that complies with the requirements specified in Section 2.4. Theodore Baker has proposed in [Baker:07] a necessary and sufficient schedulability test for arbitrary-deadline sporadic tasks scheduled by Global- but its time-complexity is very high so only small applications can be tested. Fortunately, many sufficient schedulability tests have been proposed for scheduler such as Global- (see for instance [BakerBaruah:09, Baruah:10, BaruahGoossens:08, BaruahBaker:08, BertCiriLipari:05]) and Global-DM (see for instance [Baker:03, BaruahGoossens:08:2, BaruahFisher:07]).. Algorithm 9 provides a pseudo-code for protocol .

0:  : the old mode 0:  : the new-mode 0:  the rem-jobs 0:  : the current time during the transition 0:  : the platform (uniform or identical) 1:  if ( is the invoking time) then 2:     Disable all the tasks of 3:     Sort the task set “” by non-decreasing order of transition deadlines 4:      5:  end if 6:  Schedule the rem-jobs according to 7:  if (any rem-job completes at on any then 8:      number of active rem-jobs at time 9:     if (then 10:        /* Due to the completion of , one becomes available. */ 11:        if ( is identical) then 12:           /* The scheduler is weakly work-conserving. Thus, the that becomes available is */ 13:            14:        else 15:           /* The scheduler is strongly work-conserving. Thus, the that becomes available is the slowest . */ 16:            17:        end if 18:     end if 19:     for each  do 20:         21:        if (then 22:           enable 23:        end if 24:     end for 25:     if (then 26:        enter the new-mode 27:     else 28:        Schedule all the rem-jobs and new-mode jobs according to 29:     end if 30:  end if
Figure 9: protocol
Observation 1

The whole “if–else–endif” block within lines 11–17 could be replaced with as adding (instead of ) to does not make any difference if is identical. However, we preferred to provide the reader with this longer version of the algorithm for sake of pedagogy. The shorter version explained here will be used in the Validity Algorithm 10 presented on page 10.

4.2 Design of a validity test

For a given application and platform , the main idea to determine whether allows to meet all the transition deadlines is to run Algorithm 9 for every possible mode transition, while considering the worst-case scenario for each one—the scenario in which the new-mode tasks are enabled as late as possible. From our definition of protocol , we know that every instant at which some new-mode tasks are enabled corresponds to an instant at which at least one has no more rem-job to execute, i.e., an “idle-instant” defined as follows.

Definition 13 (Idle-instant )

Let be any finite set of synchronous jobs. Let be a uniform multiprocessor platform and let be the job priority assignment used during the schedule of upon . If denotes that schedule then the idle-instant (with ) is the earliest instant in such that at least s idle.

By definition of the protocol , and in particular from the definition of , a new-mode job never preempts a rem-job during the transition phases. Thereby, during every transition phase, new-mode tasks are enabled at each idle-instant () where is the set of rem-jobs at the invoking time and is the job priority assignment derived from the old-mode scheduler when the mode change is requested. For obvious reasons, the exact values of these idle-instants depend on both the number of jobs in and their actual execution times. Therefore, these exact value cannot be determined at system design-time and the main idea of our validity test is the following.

First, for every mode we determine the set of rem-jobs that leads to the largest idle-instants (). From this point forward, we thus refine the definition of the critical rem-job set as follows.

Definition 14 (Critical rem-job set )

Assuming any transition from a specific mode to any other mode , the critical rem-job set is the set of jobs issued from the tasks of that leads to the largest idle-instants.

As it will be shown in Corollary 1 (page 1), the critical rem-job set of every mode is the one that contains one job for each task and such that every job has a processing time equals to , i.e., the WCET of . Informally speaking, the worst-case scenario during any mode transition is the one in which (i) every old-mode task releases a job exactly when the mode change is requested and (ii) every released job executes for its WCET.

Second, we determine (for any given set of jobs) an upper-bound on each idle-instant (for ). As in the previous section (and for the same reason), we distinguish between FTP and FJP schedulers. That is, for FTP schedulers we focus on determining an upper-bound on each idle-instant (for ) assuming that the job priority assignment is known beforehand, whereas for FJP schedulers, we determine an upper-bound on each idle-instant , with the interpretation that for every job priority assignment :

Finally, we simulate Algorithm 9 at each of these upper-bounds. That is, we verify whether all the transition deadlines are met while enabling the new-mode tasks at each instant (or depending on the family of the old-mode scheduler). Obviously, if every transition deadline is met during this simulation then it will be met during the actual execution of the application.

It goes without saying that the prior knowledge of the jobs priority assignment allows for establishing tighter upper-bounds on the idle-instants, i.e., the upper-bounds are tighter than . Notice that it results from these notations that and correspond to the upper-bounds and introduced in Validity Test 1, respectively.

Mathematical expressions of these upper-bounds and on the idle-instants are defined for both identical and uniform platforms in Sections 69. Algorithm 10 provides details on the validity test for , where the upper-bounds must be replaced with at line 9 if the old-mode scheduler is FTP.

0:   1:  for (all such that do 2:      3:      4:      5:     Sort by non-decreasing order of transition deadlines 6:     for (do 7:         8:        for (all do 9:           if (then 10:              return  false 11:           end if 12:           if (then 13:               14:               15:           end if 16:        end for 17:     end for 18:  end for 19:  return  true
Figure 10: Validity Test for

Notice that Algorithm 10 enables new-mode tasks only at the instants (with ). That is, it implicitly considers that every instant at which s become available to the new-mode tasks are as late as possible. As a consequence, if all the transition deadlines are met while running Algorithm 10 then all these deadlines will be met during every transition phase at run-time999Because Algorithm 10 considers every transition between every pair of modes of the application.. Nevertheless, the fact that Algorithm 10 simulates every idle-instant of every mode transition by its corresponding upper-bound brings about the following situation: during the actual execution of the application, there could be some intervals of time (during any mode transition) during which the set of currently enabled new-mode tasks benefits from more (and faster) s than during the execution of Algorithm 10. This kind of situation can occur upon identical and uniform platforms and for both FJP and FTP schedulers as shown in the following example.

Example 5

Let us consider a -processors uniform platform  and a system which is transitioning from mode to mode . Other details such as the speeds, the characteristics of the jobs and the job priority assignment are not relevant in the scope of this example. Figures 11 and 12 illustrate a situation where during some intervals of time the set of currently enabled new-mode tasks benefits from more (and faster) s than during the execution of Algorithm 10.

Figure 11: Illustration of the schedule assumed by the execution of Algorithm 10. In this schedule, new-mode tasks are enabled at each instant , .
Figure 12: Illustration of a possible schedule during a transition from mode to mode in the actual execution of the application. Here, new-mode tasks are enabled at each instant , , where .

For sake of clarity, Figure 12 uses the notations and instead of and , respectively. In this latter schedule, there can be less rem-jobs and/or rem-jobs with lower processing times than in the schedule of Figure 11 since the schedule of Figure 11 is drawn while assuming the critical rem-job set of mode . This is the reason why the schedule of Figure 12 seems less “loaded” than the one of Figure 11. Due to the fact that (i) the validity test provided by Algorithm 10 uses the same function as protocol at run-time and (ii) this function is independent of the current time, we know that the set of tasks enabled at each instant () in Figure 12 is the same as the set of tasks enabled at each instant in Figure 11. Let us temporarily name this property the “equivalence property”. Let temporarily denote the set of tasks enabled at time , and suppose that at time in Figure 11 some tasks are enabled (i.e., ) and at time no task is enabled, i.e., . Thanks to the equivalence property, we know that the tasks enabled at time in Figure 12 are the tasks of and those enabled at time are the tasks of . Since we assumed in Figure 12 that , it holds that the tasks enabled at time are the tasks of (since ). It follows that in the time interval , only s are available to the task set in Figure 11 while