Reconfigurable Priority Ceiling Protocol
Under Rate Monotonic Based Real-time Scheduling
Maroua Gasmi
1,2
, Olfa Mosbahi
2
, Mohamed Khalgui
2
and Luis Gomes
3
1
Computer Science Departement, Faculty of Science of Tunis, University Tunis el Manar, Tunis, Tunisia
2
Computer Science Departement, LISI Lab, INSAT Institute, University of Carthage, Tunis, Tunisia
3
Departamento de Engenharia Electrotcnica, Faculdade de Ciłncias e Tecnologia,
Universidade Nova de Lisboa, Caparica, Portugal
Keywords:
Real-time System, Reconfiguration, Scheduling, Resource Sharing, Priority Ceiling Protocol.
Abstract:
This research paper deals with reconfigurable real-time systems to be adapted to their environment under user
requirements. A reconfiguration scenario is a run-time software operation that allows the addition, removal
and update of real-time OS tasks which can share resources and should meet corresponding deadlines. We
propose a new Reconfigurable Priority Ceiling Protocol (denoted by RPCP) that avoids deadlocks after any
reconfiguration scenario and changes the priorities of tasks in order to reduce their response and blocking
times, and to meet their deadlines. This protocol requires the use of two virtual processors in order to guarantee
the non-interruption of execution during the reconfiguration step. We develop a tool that encodes this protocol
which is applied to a case study.
1 INTRODUCTION
Real-time constraints (Stankovic, 1996) are common
bases to most of the actual embedded systems (Lee
et al., 2007), since the latter have many time require-
ments imposed on their activities. These systems
follow a definite classification (Colnaric and Verber,
2007). The functions performed by the real-time sys-
tems, are consistently, executed by a fixed number of
tasks. Nevertheless, the notion of time is what makes
the difference between real-time and non-real-time
systems. The main rule is that the preeminent param-
eter, the deadline, has to be met under even the worst
circumstances (Kalinsky, 2003). In the case where
several tasks share a specific number of resources,
many issues can occur preventing these tasks from
meeting their deadlines. In the perspective of solving
these problems, Rate Monotonic schedule (Lehoczky
et al., 1989), is a scheduling algorithm that assigns
priorities on the basis of the period of the task. Al-
though, this algorithm, solves the mentioned prob-
1
This research paper is a collaboration between LISI
Lab (INSAT at University of Carthage in Tunisia), PASRI
(Ministry of High Study and Research in Tunisia) and Uni-
versidade Nova de Lisboa in Portugal. It is financially sup-
ported as a MOBIDOC grant from the European Commis-
sion. We thank Mr. Wael Bouslama for his fruitful collabo-
ration in the experimental part.
lems, others can occur as a consequence. In fact, a
high priority task can be interrupted by a lower prior-
ity one, inverting the priorities of the two tasks (Sha
et al., 1990). This problematic scenario, called pri-
ority inheritance, is solved by dint of a synchroniza-
tion protocol called priority ceiling protocol (PCP).
Furthermore, a real-time system has the ability to
be reconfigured according to its surroundings (Bren-
nan et al., 2002). In fact, a reconfiguration consists
on modifying the behavior of the system depending
of the modifications that occurred in its environment
(Wang et al., 1995). The reconfiguration can either be
static, where it is only applied offline before the start-
ing of the system, or dynamic (Stewart et al., 1997).
The dynamic form of reconfiguration can be either
manual (applied by a user) or automatic (applied by
intelligent agents within the system). In the literature,
the concept of reconfiguration that we are introduc-
ing in this paper is indicated as a mode change since a
system is able to move from one mode of execution to
another. A mode change is defined as the removal of
tasks, the addition of new ones and the change of their
parameters (Sha et al., 1989). As a matter of fact, the
particularity of the work that we propose in this paper
lies, essentially, in the possibility of reconfiguring the
resources as well as the set of tasks, optimizing the
blocking times and lowering the response times after
42
Gasmi M., Mosbahi O., Khalgui M. and Gomes L..
Reconfigurable Priority Ceiling Protocol - Under Rate Monotonic Based Real-time Scheduling.
DOI: 10.5220/0005060900420052
In Proceedings of the 11th International Conference on Informatics in Control, Automation and Robotics (ICINCO-2014), pages 42-52
ISBN: 978-989-758-039-0
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
each scenario of reconfiguration. However, several
authors treated the mode change, proposing different
techniques. None of these techniques offers the ad-
vantages previously mentioned. In (Real and Crespo,
2004) the authors present a classification and an eval-
uation of mode change protocols for single-processor,
fixed priority, preemptively scheduled real-time sys-
tems. The contribution in (Stoimenov et al., 2009)
consists on presenting a method for timing analysis
of single-processor multi-mode systems with earliest
deadline first (EDF) or fixed priority (FP) scheduling
of tasks. In (Tindell et al., 1992) the mode changes are
defined either as operations increasing a task sets pro-
cessor utilization, or operations that decrease it. The
analysis approach in the latter work is improved and
extended to deadline-monotonic scheduling in (Pedro
and Burns, 1998). The model is augmented with tran-
sition offsets in (Pedro and Burns, 1998), which per-
mits to avoid overload situations. In the idle time
protocol (Tindell and Alonso, 1996), when a mode
change request occurs, the activation of the new tasks
is not done until the next idle instant takes place. Al-
though its implementation is simple, the latter proto-
col is considered to be poor when it comes to prompt-
ness. The ceiling protocol in Multi-Moded Real-Time
Systems (Farcas, 2006) is an approach that combines
the mode changes and permits an important degree of
flexibility with immediate inheritance priority ceiling
protocol (IIPCP). In the works presented in (Gharbi
et al., 2013; Gharbi et al., 2011; Khalgui et al., 2011)
the Priority Ceiling Protocol (PCP) is applied as an
approach to ensure the scheduling between periodic
tasks but the change of priorities of these tasks in
order to minimize the response time reconfiguration
is not taken into account. Generally speaking, in a
random scenario of reconfiguration, the problems of
deadlock and exceeding of deadline can occur. No
one in the related works treated this situation where
we can have activations of resources and tasks. we
propose an original solution, denoted as Reconfig-
urable Priority Ceiling Protocol (RPCP) to the pre-
viously defined problems, in addition to the optimiza-
tion of blocking and response times. To guarantee the
non interruption of execution after any reconfigura-
tion scenario, the proposed solution starts by separat-
ing the physical processor into two virtual ones. The
first continues the regular execution of PCP, while the
second one calculates the new periods and therefore
priorities that guarantee the previously defined opti-
mizations. We developed a simulation tool at LISI
Lab (University of Carthage) which is applied to a
case study in order to show the contributions of the
paper.
The following section gives an overview on the dif-
ferent axes that create the context of the work. the
section case study takes an example of reconfigurable
tasks and resources and shows the impact of the ran-
dom reconfiguration on causing issues in the sys-
tem. After that, we formalized the elements that form
mathematically our environment. Then we explain
our contribution step by step and finish by presenting
the proposed algorithm and exposing the simulation.
2 BACKGROUND
A real-time task (Liu and Layland, 1973), designated
in this paper as τ
i
, is essentially characterized by its:
(i) Arrival time A when τ
i
becomes ready for execu-
tion, (ii) Computation time C known as Worst Case
Execution Time (WCET), this parameter has to be de-
termined previously, (iii) Deadline D is the time limit
by which τ
i
must be accomplished, (iv) Starting time
S is the moment when the system decides to start τ
i
.
Indubitably, it cannot be earlier than the arrival time
A as before this time the task is totally unknown, (v)
Finish time E is the time when the execution of τi
finishes. It can be depicted by the sum of the start-
ing time S and the computation time C, (vi) Period T
which serves as a duration of one cycle on a repeating
execution of a periodic task and represents the interval
between two consecutive activations. It is important
to mention that in the case of an aperiodic task, the
concept of period is utterly missing, (vii) Work Left
W is the work left for a task to execute and finally
(vii) response time R is the length of time from the
moment of release to the instant when the task com-
pletes its execution. This time is given by the follow-
ing formula (Tokuda et al., 1990):
R
0
k
= 0, R
q
k
= C
k
+ B
k
+
j>k
&
R
q1
k
T
j
'
C
j
The response time of a task, denoted as R
k
, is ob-
tained once R
k
= R
q
k
= R
q+1
k
. During its execution,
a task is able to use one or several resources, refer-
ring by the latter to any shared hardware or software
object (Mok et al., 2001). The execution runs reg-
ularly, until the moment when several tasks wish to
use a single resource (Lipari and Bini, 2003). It is
necessary to mention that a blocking can be caused
when several tasks wish to access a single resource
(Tokuda et al., 1990). Here comes the role of the real-
time scheduling. Its main goal is to assign processors
and resources to tasks in such a way that all the im-
posed constraints are respected. Among the schedul-
ing algorithms, Rate Monotonic scheduling (Liu and
Layland, 1973) occupies an important role. It assigns
ReconfigurablePriorityCeilingProtocol-UnderRateMonotonicBasedReal-timeScheduling
43
priorities in a static way: the shorter the period of the
task the higher its priority. In (Sha et al., 1990) the
authors prove that this scheduling protocol is optimal
among the rest of static policies . One major limita-
tion of fixed-priority scheduling is that it is not always
possible to fully utilize the CPU (Sha et al., 1990).
The schedulability test for RMS is:
U =
n
i=1
Ci
Ti
n (2
1
n
1)
In a system with shared resources, it is impossible
to eliminate all priority inversions but it is possible
to limit the waiting time to minimize time and pre-
dict blocks. For this, several approaches are intro-
duced. PCP prevents the deadlock situation as well
as chained blocking (Sha et al., 1990). The rules in
PCP aim essentially to prohibit a task to enter the
critical section if there were any semaphores that may
block this task. This protocol supposes that every task
has a fixed priority and the used resources are known
before the starting of the execution (Chen and Lin,
1991). In this protocol each resource is assigned a
priority ceiling, which is a priority equal to the high-
est priority of any task which may lock the resource.
Hence, it should be taken into consideration that un-
der the priority ceiling protocol, a task is blocked at
most once, by a lower priority task, for the duration
of a critical section, no matter how many tasks con-
flict with it. With the given information in (Liu et al.,
2000), computing the maximum blocking time Bi for
a task is possible. Above all else, we should point out
that blocking time, when using PCP in particular, may
arise under 3 possibilities: Directly blocked tasks, In-
heritance blocked tasks or Avoidance blocked tasks.
Therefore, the proposed protocol RPCP is based upon
both RM and PCP since the first is optimal and the
second is useful for shared resources; In fact, it is cus-
tomized to fit the feasibility test and the condition im-
posed by RM. Besides, the particularities of this pro-
tocol lie in its ability to change priorities, reconfigure
both tasks and resources and minimize the response
as well as the blocking times.
3 CASE STUDY
We present in this section a case study to expose our
problem, and to be assumed in the following as a run-
ning example. Let us consider a system to be sched-
uled by both PCP and RM, and to be implemented by
OS tasks with shared resources. The details related
to these tasks are given by Table1. The task τ
1
for
example is periodically executed each 60 time units,
and uses the resource R1 for 5 time units.
Table 1: Parameters of the initial tasks.
Tasks Priorities Resources Computation times (Ci) Periods (Ti)
τ
1
P1 R1 5 60
τ
2
P2
R1 2
55
R2 3
τ
3
P3 R2 5 50
τ
4
P4
R5 2
45R6 3
R8 2
τ
5
P5
R6 4
40
R7 3
According to the simulator Cheddar (Singhoff et al.,
2004), the system is feasible since all the tasks meet
the related deadlines as depicted in Figure 1. We can
prove the system feasibility by applying the RM con-
dition
5
i=1
Ci
Ti
= 60% and is lower than 5 (2
1
5
1) =
74%. We are interested in the current work in the soft-
ware reconfiguration of tasks and resources. A recon-
figuration is assumed to be an operation allowing the
addition-removal of tasks or resources. No one in all
related works dealing with real-time scheduling treats
this form of reconfiguration. Let we assume the fol-
lowing reconfiguration that adds the tasks τ
6
and τ
7
,
and removes τ
4
and τ
5
under well-defined conditions
described in user requirements.
Figure 1: Execution graph of the tasks.
Table 2 depicts in detail the new configuration of the
system.
Table 2: Parameter of the tasks after reconfiguration.
Tasks Priorities Resources Computation times (Ci) Periods (Ti)
τ
1
P1
R1 8
60
R4 12
τ
2
P2
R1 15
55
R2 5
τ
3
P3
R2 3
50
R3 17
τ
6
P6
R3 14
45
R4 6
τ
7
P7
R4 2
40
R1 18
Note that this reconfiguration scenario can allow the
violation of real-time properties or block and destroy
the whole system in some situations, since the new
tasks have higher priorities and the old ones have to
use new resources. We show in Figure 2 the run-time
ICINCO2014-11thInternationalConferenceonInformaticsinControl,AutomationandRobotics
44
problem that occurs in the system after this reconfig-
uration scenario. In fact, while τ
1
is holding the re-
source R
1
, the reconfiguration adds the resource R
4
to
the list of the resources belonging to the latter task.
τ
7
, the task added after the application of this sce-
nario, finishes the execution of R
4
and keeps waiting
for R
1
as shown in Figure 2. A deadlock happens in
this situation.
Figure 2: Deadlock due to the reconfiguration scenario.
The random application of the new configuration
causes a deadlock leading automatically to the vi-
olation of the feasibility conditions. In the related
works the deadlock problem was cured but without
taking into account the optimization of the compu-
tation time neither the possibility of minimizing the
blocking times and the response times of the different
tasks. The addition and removal of resources within
the system as well as changing the priorities of the
tasks are original particularities in our work that we
cannot find in other works.
In this section, the remarked problem is essentially
due to an arbitrary choice of priorities after a recon-
figuration scenario. For this reason, we introduce in
this paper, a new solution that does not only consist on
preventing any deadlocks owing to a sudden change
in the set of tasks caused by an incoming reconfigura-
tion, but also on drafting suitable priorities that offer
minimal blocking times for each task.
4 FORMALIZATION
In this section, we are interested in mathematically
defining the elements of the system and their reactions
to any reconfiguration scenario as well as the pro-
posed representation of their characteristics. Hence,
in addition to the existing parameters, mentioned in
the section background, we propose to add the fol-
lowing new ones to each task. (i) π(t): the state of
a task within the system (1 if the task is active either
executed or not, 0 else). (i) σ: the set of possible re-
sources that can be used by the task, (ii) Res(t): the
set of resources used by the task at t, (iii) Cond(t):
state of conditions (1 if the condition that activates
the task is met at t, 0 if not) and (iv) Request(t): the
set of resources required by the task at t. Let τ
Sys
and
R
Sys
respectively be the set of all possible tasks and
resources that may be executed within the system in-
dependently from the time. Therefore, a general sys-
tem that describes the global environment, denoted as
Sys, is defined by the previously mentioned couple.
Sys = (τ
Sys
,R
Sys
) (1)
Running example1:
Through the example given in the case study τ
Sys
and R
Sys
are expressed as follows:
τ
Sys
= {τ
1
,τ
2
,τ
3
,τ
4
,τ
5
,τ
6
,τ
7
}
R
Sys
= {R
1
,R
1
,R
3
,R
4
,R
5
,R
6
,R
7
,R
8
}
Let τ
Sys
(t) and R
Sys
(t) respectively be the set of active
tasks and resources within the system at a given mo-
ment t. Pointedly, the set of active tasks , denoted as
τ
Sys
(t) at the moment t is represented by the group of
tasks whose the state is set to be active. This assort-
ment is given by the following formula:
τ
Sys
(t) = {τ
i
τ
Sys
/τ
i
.π(t) = 1} (2)
Respectively, the group of resources which are active
at t , denoted as R
Sys
(t), is represented by the re-
sources required by the active tasks at that moment.
This set of resources is given by the following for-
mula:
R
Sys
(t) = {R
i
R
Sys
/τ
i
,τ
i
.π(t) = 1 R
i
τ
i
.Request(t)}
(3)
As a consequence, the general system at that moment,
denoted as Sys(t), is defined by the previously men-
tioned couple.
Sys(t) = (τ
Sys
(t), R
Sys
(t)) (4)
Running example 2:
Through the example given in the case study, Ta-
ble1 contains the list of the active tasks and re-
sources at t
0
before the application of the recon-
figuration scenario. As a consequence, τ
Sys
(t
0
)
and R
Sys
(t
0
) are expressed as follows:
τ
Sys
(t
0
) = {τ
1
,τ
2
,τ
3
,τ
4
,τ
5
}
R
Sys
(t
0
) = {R
1
,R
2
,R
5
,R
6
,R
7
,R
8
}
According to user requirements, each reconfiguration
scenario is automatically applied to add or remove
tasks from a system at a specific moment denoted as
t
1
. In fact, the couple τ
Sys
(t
0
) and R
Sys
(t
0
) that takes
place at t
0
, which is a moment coming right before the
ReconfigurablePriorityCeilingProtocol-UnderRateMonotonicBasedReal-timeScheduling
45
reconfiguration, is replaced by τ
Sys
(t
1
) and R
Sys
(t
1
).
Let ξ
Sys
(t
1
),described by the formula (5), be the group
of tasks to be added to the system. In fact, a task is
ready to be added when the condition that activates it
is met at t
1
.
ξ
Sys
(t
1
) = {τ
i
τ
Sys
/τ
i
.Cond(t
1
) = 1} (5)
Let
Sys
(t
1
),described by the formula (6), be the
group of tasks to be removed from the system. Simi-
larly, a task is ready to be removed when the condition
that deactivates it is met at t
1
.
Sys
(t
1
) = {τ
i
τ
Sys
(t
1
)/τ
i
.Cond(t
1
) = 0} (6)
Thereby, the new set of active tasks at t
1
after re-
configuration is expressed as the addition of the tasks
ξ
Sys
(t
1
) and the removal of the tasks
Sys
(t
1
) from the
old set of tasks established at t
0
. The formula describ-
ing τ
Sys
(t
1
) is given as follows:
τ
Sys
(t
1
) = τ
Sys
(t
0
) ξ
Sys
(t
1
) \
Sys
(t
1
) (7)
Running example 3:
Through the example given in the case study, the
changes from Table1 to Table2 represent a recon-
figuration scenario that occurred in t
1
. In fact, the
actions of addition and removal of tasks are per-
formed. In our case, the added tasks (ξ
Sys
(t
1
))
and the removed ones (
Sys
(t
1
)) are given as fol-
lows:
ξ
Sys
(t
1
) = {τ
6
,τ
7
}
Sys
(t
1
) = {τ
4
,τ
5
}
Subsequently, the new set of active tasks after
reconfiguration (τ
Sys
(t
1
)) is expressed as follows:
τ
Sys
(t
1
) = τ
Sys
(t
0
) ξ
Sys
(t
1
) \
Sys
(t
1
) =
{τ
1
,τ
2
,τ
3
,τ
6
,τ
7
}
Likewise, the subset of resources can be modified by
the reconfiguration. Let ξ
R
(t
1
) ,described by the for-
mula (8), be the group of resources to be added to the
system. In fact, a resource is considered to be active
when it is added to the system as required by a task
added through ξ
Sys
(t
1
).
ξ
R
(t
1
) = {R
i
R
Sys
/τ
j
ξ
Sys
(t
1
)R
i
τ
j
.Request(t
1
)}
(8)
However, the list of resources which need to be deac-
tivated is described by the ones that are no longer re-
quired by any task. It is to mention, that if a resource
is shared by several tasks, it cannot be removed when
some of them are removed. The group of resources
which cannot be removed is denoted by
R
(t
1
) and
described by the formula (9).
R
(t
1
) = {R
i
R
Sys
(t
1
)/τ
j
τ
Sys
(t
1
) \
Sys
(t
1
),
R
i
τ
j
.Request(t
1
)}
(9)
Conclusively, the set of resources to be deactivated
is defined as the relative complement of R
Sys
(t
1
) in
R
(t
1
) and described by the following formula:
R
(t
1
) = R
Sys
(t
1
) \
R
(t
1
) (10)
Finally the new set of active resources after recon-
figuration (R
Sys
(t
1
)) is expressed as the addition of
resources ξ
R
(t
1
) and the removal of the tasks
R
(t
1
)
from the old set of tasks established at t
0
. The formula
describing R
Sys
(t
1
) is given as follows:
R
Sys
(t
1
) = R
Sys
(t
0
) ξ
R
(t
1
) \
R
(t
1
) (11)
Running example 4:
Continuing from the previous running example,
the added resources (ξ
R
(t
1
)) and the removed
ones (
R
(t
1
)) are given as follows:
ξ
R
(t
1
) = {R
3
,τ
4
}
R
(t
1
) = {R
5
,R
6
,R
7
,R
8
} Subsequently, the new
set of active resources after reconfiguration
(R
Sys
(t
1
)) is expressed as follows:
R
Sys
(t
1
) = R
Sys
(t
0
) ξ
R
(t
1
) \
R
(t
1
) =
{τ
1
,τ
2
,τ
3
,τ
4
}
5 CONTRIBUTION RPCP/RM
We propose in this section to resolve the paper’s orig-
inal problems that we detailed in the case study. In
fact, the automatic reconfiguration of tasks and/or re-
sources can lead the system to deadlocks or the pos-
sible violation of deadlines by new or old tasks. Ex-
plicitly, the deadline is violated when a corresponding
task has some work left when it reaches it. As for the
deadlock, it happens when a task holds resources that
another one is waiting for and inversely.This is prop-
erly explained in the following formula:
Problem :
τ
i
/τ
i
.W > τ
i
.D t
1
τ
i
,τ
j
/τ
i
.Request(t
1
) τ
j
.Res(t
1
) 6=
/
0
τ
j
.Request(t
1
) τ
i
.Res(t
1
) 6=
/
0
(12)
As a consequence to the mentioned problems, the exe-
cution of the hardware processor is split into two vir-
tual processors in the purpose of pre-computing the
proposed optimizations when applying the reconfig-
uration at t
1
. One of the virtual processors continues
the normal execution of old tasks normally without in-
terruption while the other one computes the right set
of periods and priorities. The latter mentioned proce-
dure is decomposed in several sub-steps: the blocking
time minimization of the new and old tasks, response
ICINCO2014-11thInternationalConferenceonInformaticsinControl,AutomationandRobotics
46
time minimization, assuring feasibility without dead-
lock due to the addition of resources and meeting the
RM condition.
5.1 Virtual Processors
In order to guarantee the non-interruption of the exe-
cution of the system, spreading the physical processor
into two distinguished virtual processors, which are
time slots, was taken into consideration. The idea be-
hind this, is to gain in terms of computation without
having any time gaps during the execution of the old
tasks. In this study, two virtual processors are pro-
posed. The first one, denoted as V P
1
takes the respon-
sibility of computing the new appropriate periods and
priorities to be assigned to both the old and new tasks
after reconfiguration. The second one, V P
2
, executes
normally the old tasks by using the regular PCP. Fig-
ure 3 explains how the two virtual processors operate
in order to switch safely from a configuration to an-
other without interrupting the current execution.
Figure 3: Roles of the virtual processors within the system.
The instant t
1
, like we mentioned before, corresponds
to when exactly the reconfiguration request occurred,
t
2
when the computation ended and t
3
when V P
2
ends
the freeing of resources. In fact, V P
2
executes the old
tasks and it does not switch to the new configuration
until V P
1
finishes its computation and reveals the new
assortment of priorities and periods related to each
task. The step that proceeds the switch from a config-
uration to another, consists on allowing the tasks that
hold some resources to finish their execution under
the previous configuration. Let Newconf be the group
of tasks saved at t
1
to be used in the computation done
by V P
1
. It is formulated by using (7). However, at
t
1
, τ
Sys
(t
1
) changes and represents the group of tasks
which did not finish their execution time when the re-
configuration took place. It is therefore given by the
following formula:
τ
Sys
(t
1
) = {τ
i
τ
Sys
(t
0
)/τ
i
.S < t
1
τ
i
.W (t
1
) 6= 0}
(13)
As a consequence, The group of resources R
Sys
(t
1
)
within the actual system depends on the change that
occurred to τ
Sys
(t
1
) as remarked in the formula (3).
Thus, the moment t
3
, previously described as when
V P
2
ended freeing the resources, is disposed by the
following formula:
t
3
= max(τ
i
.E
i
/τ
i
τ
Sys
(t
1
)) (14)
The phase of computation to be realized by V P
1
, con-
sists on finding the right set of periods and priorities.
After this phase, the actual virtual processor VP
2
will
be able to run under the new configuration. The exact
moment when the latter virtual processor starts ap-
plying the new configuration is depicted as t
new
and
described as follows:
t
new
= max(t
2
,t
3
) (15)
Running example 5:
Proceeding further in the example given in the
case study, the results obtained at t
1
, t
2
, t
3
and
t
new
are explained in details. At t
1
, Newconf =
{τ
1
,τ
2
,τ
3
,τ
6
,τ
7
} and τ
Sys
(t
1
) = {τ
1
}. At t
2
, V P
1
finishes the computation and the application of
the new periods and priorities of the task set
Newconf. At t
3
, τ
1
finishes executing R
1
. At t
new
,
τ
Sys
(t
new
) = Newconf.
5.2 Appropriate Set of Periods
At t
new
, V P
2
is able to run the new set of tasks re-
sulting from the computation done by V P
1
. In our
contribution, τ
Sys
(t
new
), previously defined in (7), is
described as the modification of the priorities and pe-
riods that belong to the group of tasks Newconf gener-
ated from the reconfiguration request. This modifica-
tion that we propose, described in the formula (16), is
performed by the recursive function Ψ which is com-
puted in several steps.
τ
Sys
(t
new
) = Ψ(Newcon f ) (16)
Furthermore, in order to calculate the new temporal
configurations of tasks, some steps need to be fol-
lowed. the function Ψ is the composition of several
other sub-functions such that each of one corresponds
to a step of calculation.This is shown by the formula
(17).
Ψ = Ψ
4
Ψ
3
Ψ
2
Ψ
1
(17)
In fact, to calculate the new system configura-
tion τ
Sys
(t
new
), we need to compute at first time,
Ψ
1
(Newcon f ) which is in charge of finding the right
arrangement of priorities that ensures a minimum
blocking time. Then we apply the sub-function Ψ
2
to
the result of Ψ
1
(Newcon f ) which is responsible for
finding the right periods for which the response time
of each task is minimum. Ψ
3
is applied to the result of
Ψ
2
: it is bound to find the periods for which the dead-
line constraint is respected. And finally, Ψ
4
is applied
ReconfigurablePriorityCeilingProtocol-UnderRateMonotonicBasedReal-timeScheduling
47
to the result of Ψ
3
: it adjusts the obtained periods to
meet the condition of RMS. It is to mention, that these
recursive functions are not contradictory and that they
are applied to this configuration without proposing
apposed values.
5.2.1 Ψ
1
: Minimum Blocking Time
For the purpose of identifying the minimum array of
blocking times related to the tasks, we use an algo-
rithm that reads through all the possible arrangements
of priorities that the tasks may have. Thereafter, it
spots the right set for which the blocking times are
at their minimum. The number of possibilities of
priorities that a vector of tasks can have, is based
on the same principle in combinatorics. For each
of these arrangement possibilities, the corresponding
array of blocking times is computed. Accordingly,
the comparison between the resulting vectors is per-
formed by the calculation of the Euclidean norm. As
a result, the proposed function Ψ
1
is defined as a n-
tuple formed by pairs of priorities and tasks. Let {(
P
1
,τ
1
),..., (P
n
,τ
n
)} denoted as E
1
be the actual n-tuple
corresponding to the group of tasks Newconf and {(
P
j
,τ
1
),..., (P
k
,τ
n
)} denoted as E
2
be the resulting ar-
rangement of tasks. The definition of the function is
regarded by the following formula:
Ψ
1
: E1 E2
/(P
i
,τ
i
) E
2
:
s
n
i=1
τ
i
.B
2
= min(
v
u
u
t
n
k=1,(P
k
,τ
k
)E
1
τ
k
.B
2
)
(18)
Where [P
j
,..., P
k
] is the same as the vector of priorities
[P
1
,..., P
n
] just in a different order of its elements. It
is important to retain that the priority with the least
index is the highest among all priorities.
Running example 6:
This example aims to find the right set of priori-
ties that guarantee a minimum blocking time for
each task in Newcon f . The following table con-
tains the resulting minimum blocking time and
the corresponding new priority to each task.
Tasks Initial blocking times Minimum blocking times Old Priority new priority
τ
1
0 6 P
5
P
4
τ
2
12 12 P
4
P
3
τ
3
15 14 P
3
P
1
τ
6
17 0 P
2
P
5
τ
7
15 15 P
1
P
2
The norm of the values of the initial blocking
times is 29,71. As for the one corresponding to
the Minimum blocking times, its value is 24,51.
5.2.2 Ψ
2
: Minimum Response Time
Once the first step dealing with Ψ
1
is done we apply
its result to the function Ψ
2
. Attaining a specific set
of priorities, is only effective when it comes to ac-
quiring the appropriate values of periods. As matter
of fact, the next step consists on finding the right pe-
riods for which the response time of each task is at
its minimum. In this contribution, we can define the
minimum response time that a task can have (as long
as the priority of the latter is not the maximum) as the
sum of its blocking time, its execution time and the
execution times of the tasks that are more prioritized.
For each task τi, the minimum response time, denoted
as R
i,min
, is therefore given by the following formula:
R
i,min
=
(
C
i
+ B
i
i f P
i
= max(P
1
,...,P
n
)
C
i
+ B
i
+
P
k
>P
i
C
k
else
(19)
The obtained response times allow the possibility of
defining the boundaries of the period. In fact, the gen-
eralization consists on limiting the periods of all the
tasks (except the one with the lowest priority) with
the maximum of response times among the least pri-
oritized ones. Referring to the previous analysis, let
τ
prior
be the set of tasks except the least prioritized
(respecting the order set by Ψ
1
). The function Ψ
2
replaces the values of periods of tasks belonging to
τ
prior
with the maximum of response times of the pri-
oritized tasks incremented by one. This is given by
the following formula :
Ψ
2
: τ
i
.T max(R
k
) + 1/k : P
k
< P
i
(20)
Running example 7:
After assigning new priorities to the given tasks
mentioned in the case study, the process of find-
ing the minimum possible periods starts.
Tasks Minimum response times new periods
τ
1
11 23
τ
2
22 23
τ
3
19 45
τ
6
22 0
τ
7
44 23
Since τ
6
has the lowest priority, no period value
is affected to it yet.
5.2.3 Ψ
3
: Feasibility Test
Once the application of Ψ
2
is done, he results of the
previous steps are applied to Ψ
3
. Going further in
finding the periods, the respect of the constraint of
ICINCO2014-11thInternationalConferenceonInformaticsinControl,AutomationandRobotics
48
feasibility should be promulgated. In fact, bearing in
mind the feasibility condition imposed by the system
can allow limiting the period. So far, let Boundary
k
be the inferior limit of the resulting period.
Boundary
k
=
A
k
+ R
k
i f τ
k
is the least prioritized task
max(A
k
+ R
k
,τ
k
.T )) i f not
(21)
Thus, the definition of our submitted function Ψ
3
is:
Ψ
3
: τ
k
: τ
k
.T Boundary
k
+ 1 (22)
Running example 8:
Continuing in the example of the case study, the
process of finding the possible periods that per-
mit the respect of the feasibility continues.
Tasks Starting times (A) A+R Periods obtained from Ψ
2
new Periods
τ
1
3 14 23 24
τ
2
1 23 23 24
τ
3
5 24 45 46
τ
6
2 28 0 29
τ
7
4 48 23 49
The new periods obviously correspond to the
maximum between the sum of A and R, and the
periods previously obtained from Ψ
2
.
5.2.4 Ψ
4
: RM Condition Test
Once Ψ
3
is well executed,we apply its result to Ψ
4
.
Basically, the procedure is done by incrementing the
values of the periods until fulfilling the RM condition.
Therefore, we make a place for a system that min-
imizes the response time, allows the feasibility and
respects the condition imposed by the Rate Mono-
tonic Scheduling (RMS). Hence, the function Ψ
4
is
proposed to guarantee the respect of the latter condi-
tion which is expressed by the following formula:
Ψ
4
: τ
j
: τ
j
.T τ
j
.T /
n
j=1
C j
T j
n (2
1
n
1) (23)
Running example 9:
Finally, the following table describes the list of
periods obtained after running a loop of incre-
mentation that allows to obtain the required peri-
ods of tasks that respect the RM condition.
Tasks Execution times new Periods
τ
1
5 32
τ
2
5 31
τ
3
5 53
τ
6
7 36
τ
7
7 56
It is to mention that the obtained value of τ
1
and τ
2
is the same in this example. But, since
τ
1
is less prioritized than τ
2
, we incremented it
in order to point out the distinct priorities. The
value of
5
j=1
C j
T j
is around 73% which is less than
74,35% (the value of 5 (2
1
5
1)).
5.2.5 Solution
The global function Ψ allowing the correct reconfig-
uration of the real-time system (applied to both the
old and new tasks) is composed of Ψ
1
, Ψ
2
, Ψ
3
and
Ψ
4
. It permits to have a group of tasks that imple-
ment the system while satisfying the following items:
(i) avoiding the deadlock anomaly, (ii) respecting the
RM condition as well as minimizing (iii) the response
time of the tasks and (iv) their blocking times. Sub-
sequently, the resulting group of tasks that implement
the system are free from the problems mentioned in
(12) and characterized as follow :
Solution :
(VirtualProcessors)τ
i
,τ
j
/τ
i
6= τ
j
τ
i
.Request(t) τ
j
.Rest(t) =
/
0(i)
(Ψ
1
) τ
i
/τ
i
.B = Minimum(τ
i
.B)(iv)
(Ψ
2
) τ
i
/τ
i
.R = Minimum(τ
i
.R)(iii)
(Ψ
3
) τ
i
/τ
i
.W < τ
i
.D t
1
(ii)
(Ψ
4
) τ
i
/
n
i=1
Ci
Ti
n (2
1
n
1)(ii)
(24)
6 SIMULATION
Defining the procedures mentioned in the formaliza-
tion in an algorithmic way consists on running two
distinguished threads Algorithm1. The first one exe-
cutes the actually active tasks with regular PCP. The
second computes the blocking times and right ar-
rangements of priorities , then starts the procedure of
calculating the response times and the periods. Fi-
nally it checks the feasibility and the RM Condition in
order to deliver the new information to the first thread.
For the purpose of simulating the RPCP and showing
its contribution compared to random behavior towards
reconfiguration, we developed a tool at LISI Labora-
tory of INSAT Institute (Figure 4) that allows the user
to fill in with the desired tasks parameters. Afterward,
it is possible to fill with the parameters of the tasks
that had been added to the system after the reconfigu-
ration through the interface presented in Figure 5.
ReconfigurablePriorityCeilingProtocol-UnderRateMonotonicBasedReal-timeScheduling
49
Algorithm 1 : Proposed response to Reconfiguration re-
quest.
Data: New Reconfiguration Request
Tau Sys1 tasks holding resources
NewCon f tasks resulting f rom recon f iguration
while VP1.end = False And VP2.end = False do
Tau Sys2 V P1.Execute(NewCon f )
VP2.Execute(Tau Sys1)
end
VP2.Execute(Tau Sys2)
Figure 4: Initial tasks parameters interface.
The testing of the behavior of the system before and
after the application of RPCP is pin pointed through
the interface depicted in Figure 6. It is possible to no-
tice that a blocking occurred when using the random
reaction to the reconfiguration and how this problem
was solved by using RPCP and the system continues
its execution smoothly. The response time is then
computed for each of the tasks and an average re-
sponse time for both before and after the application
of the RPCP (Figure 7). We show the gain in terms
of response time due to RPCP. Through the test done
over the case study, the improvement is noticeably ob-
vious. In fact the blocking time is managed to get
reduced to almost 80%. Consequently, the response
time decreased to 75% compared to the initial proce-
dures.
We note finally that no one in the related works
treated the problem of reconfigurable resources while
meeting deadline constraints for reconfigurable tasks.
Figure 5: Reconfiguration tasks parameters interface.
Figure 6: Execution before and after RPCP.
This tool is original and the first to treat this original
problem.
ICINCO2014-11thInternationalConferenceonInformaticsinControl,AutomationandRobotics
50
Figure 7: Response Time details.
7 CONCLUSION
In this paper, we introduce RPCP as a protocol that
solves well-defined real-time problems due to random
reaction to reconfiguration. In fact, the power within
this protocol lies on two different bases. The first one,
corresponds to the choice of well-based scheduling
methods and their ability to solve problems and opti-
mize the parameters of the system. Surely, the use of
a solid scheduling algorithm such as Rate Monotonic
and an efficient protocol like Priority Ceiling Proto-
col reflects an important benefit to conclude from the
proposed solution. Since the first one is known for its
utility and optimality in the industrial field and the
second one is able to prevent deadlocks as well as
chained blocking. The second advantage of the pro-
posed protocol RPCP, is its ability to fix the dead-
lock problems and to prevent exceeding the dead-
lines. Moreover, this protocol works on minimizing
the blocking and the response times by changing the
priorities of the tasks, leading to an optimal system
that runs effectively. We plan in the future to apply
this protocol to real complex case studies in order to
evaluate the contributions of the current paper.
REFERENCES
Brennan, R. W., Fletcher, M., and Norrie, D. H. (2002). An
agent-based approach to reconfiguration of real-time
distributed control systems. Robotics and Automation,
IEEE Transactions on, 18(4):444–451.
Chen, M.-I. and Lin, K.-J. (1991). A priority ceiling proto-
col for multiple-instance resources. In Real-Time Sys-
tems Symposium, 1991. Proceedings., Twelfth, pages
140–149. IEEE.
Colnaric, M. and Verber, D. (2007). Distributed Embed-
ded Control Systems: Improving Dependability with
Coherent Design. Springer.
Farcas, E. (2006). Scheduling multi-mode real-time dis-
tributed components. PhD thesis, PhD thesis, Depart-
ment of Computer Sciences, University of Salzburg.
Gharbi, A., Gharsellaoui, H., Khalgui, M., and Valentini, A.
(2011). Safety reconfiguration of embedded control
systems.
Gharbi, A., Khalgui, M., and Ben Ahmed, S. (2013).
The embedded control system through real-time task.
In Modeling, Simulation and Applied Optimization
(ICMSAO), 2013 5th International Conference on,
pages 1–8. IEEE.
Kalinsky, D. (2003). Basic concepts of real-time operating
systems. LinuxDevices magazine, Nov.
Khalgui, M., Mosbahi, O., Li, Z., and Hanisch, H.-M.
(2011). Reconfiguration of distributed embedded-
control systems. Mechatronics, IEEE/ASME Trans-
actions on, 16(4):684–694.
Lee, I., Leung, J. Y., and Son, S. H. (2007). Handbook of
real-time and embedded systems. CRC Press.
Lehoczky, J., Sha, L., and Ding, Y. (1989). The rate mono-
tonic scheduling algorithm: Exact characterization
and average case behavior. In Real Time Systems Sym-
posium, 1989., Proceedings., pages 166–171. IEEE.
Lipari, G. and Bini, E. (2003). Resource partitioning among
real-time applications. In Real-Time Systems, 2003.
Proceedings. 15th Euromicro Conference on, pages
151–158. IEEE.
Liu, C. L. and Layland, J. W. (1973). Scheduling algo-
rithms for multiprogramming in a hard-real-time en-
vironment. Journal of the ACM (JACM), 20(1):46–61.
Liu, F., Narayanan, A., and Bai, Q. (2000). Real-time sys-
tems. Citeseer.
Mok, A. K., Feng, X., and Chen, D. (2001). Resource par-
tition for real-time systems. In Real-Time Technology
and Applications Symposium, 2001. Proceedings. Sev-
enth IEEE, pages 75–84. IEEE.
Pedro, P. and Burns, A. (1998). Schedulability analysis
for mode changes in flexible real-time systems. In
Real-Time Systems, 1998. Proceedings. 10th Euromi-
cro Workshop on, pages 172–179. IEEE.
Real, J. and Crespo, A. (2004). Mode change protocols
for real-time systems: A survey and a new proposal.
Real-time systems, 26(2):161–197.
Sha, L., Rajkumar, R., Lehoczky, J., and Ramamritham,
K. (1989). Mode change protocols for priority-driven
preemptive scheduling. Real-Time Systems, 1(3):243–
264.
Sha, L., Rajkumar, R., and Lehoczky, J. P. (1990). Prior-
ity inheritance protocols: An approach to real-time
synchronization. IEEE Transactions on computers,
39(9):1175–1185.
ReconfigurablePriorityCeilingProtocol-UnderRateMonotonicBasedReal-timeScheduling
51
Singhoff, F., Legrand, J., Nana, L., and Marc
´
e, L. (2004).
Cheddar: a flexible real time scheduling framework.
In ACM SIGAda Ada Letters, volume 24, pages 1–8.
ACM.
Stankovic, J. A. (1996). Real-time and embedded systems.
ACM Computing Surveys (CSUR), 28(1):205–208.
Stewart, D. B., Volpe, R. A., and Khosla, P. K. (1997). De-
sign of dynamically reconfigurable real-time software
using port-based objects. Software Engineering, IEEE
Transactions on, 23(12):759–776.
Stoimenov, N., Perathoner, S., and Thiele, L. (2009). Re-
liable mode changes in real-time systems with fixed
priority or edf scheduling. In proceedings of the Con-
ference on Design, Automation and Test in Europe,
pages 99–104. European Design and Automation As-
sociation.
Tindell, K. and Alonso, A. (1996). A very simple proto-
col for mode changes in priority preemptive systems.
Universidad Polit
´
ecnica de Madrid, Tech. Rep.
Tindell, K. W., Burns, A., and Wellings, A. J. (1992). Mode
changes in priority preemptively scheduled systems.
In Real-Time Systems Symposium, 1992, pages 100–
109. IEEE.
Tokuda, H., Nakajima, T., and Rao, P. (1990). Real-time
mach: Towards a predictable real-time system. In
USENIX Mach Symposium, pages 73–82.
Wang, J.-C., Chiang, H.-D., and Darling, G. R. (1995).
An efficient algorithm for real-time network recon-
figuration in large scale unbalanced distribution sys-
tems. In Power Industry Computer Application Con-
ference, 1995. Conference Proceedings., 1995 IEEE,
pages 510–516. IEEE.
ICINCO2014-11thInternationalConferenceonInformaticsinControl,AutomationandRobotics
52