Supporting Multiprocessor Resource Synchronization Protocols in RTEMS

04/13/2021 ∙ by Junjie Shi, et al. ∙ TU Dortmund 0

When considering recurrent tasks in real-time systems, concurrent accesses to shared resources, can cause race conditions or data corruptions. Such a problem has been extensively studied since the 1990s, and numerous resource synchronization protocols have been developed for both uni-processor and multiprocessor real-time systems, with the assumption that the implementation overheads are negligible. However, in practice, the implementation overheads may impact the performance of different protocols depending upon the practiced scenarios, e.g., resources are accessed locally or remotely, and tasks spin or suspend themselves when the requested resources are not available. In this paper, to show the applicability of different protocols in real-world systems, we detail the implementation of several state-of-the-art multiprocessor resource synchronization protocols in RTEMS. To study the impact of the implementation overheads, we deploy these implemented protocols on a real platform with synthetic task set. The measured results illustrate that the developed resource synchronization protocols in RTEMS are comparable to the existed protocol, i.e., MrsP.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

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

I Introduction

In multi-tasking real-time systems, the accesses to shared resources, e.g., file, memory cell, etc., are mutually exclusive, to prevent race conditions or data corruptions. A code segment that a task accesses to the shared resource(s) is called a critical section, which is protected by using binary semaphores or mutex locks. That is, a task must finish its execution of the critical section before another task can access the same resource. However, the mutually exclusive executions of critical sections may cause other problems, i.e., priority inversion and deadlock, which could jeopardize the predictability of the real-time system. In order to guarantee the timeliness of a real-time system, a lot of resource synchronization protocols have been developed and analyzed since 1990s for both uni-processor and multiprocessor real-time systems.

In uni-processor real-time systems, the Priority Inheritance Protocol (PIP) and the Priority Ceiling Protocol (PCP) by Sha et al. [21], as well as the Stack Resource Policy (SRP) by Baker [4] have been widely studied. Since PIP may potentially lead to a deadlock requiring additional verification to avoid [14], PCP has been relatively common and its performance has been widely accepted. Specifically, a variant of PCP has been implemented in Ada (named Ceiling locking) and in POSIX (named Priority Protect Protocol).

Because of the increasing demand of computational power of real-time systems, multiprocessor platforms have been widely used. To solve the resource synchronization problem, a lot of multiprocessor resource synchronization protocols have been proposed and extensively studied, such as the Distributed Priority Ceiling Protocol (DPCP) [20], the Multiprocessor Priority Ceiling Protocol (MPCP) [19], the Multiprocessor Stack Resource Policy (MSRP) [15], the Flexible Multiprocessor Locking Protocol (FMLP) [5], the Locking Protocol (OMLP) [8], the Multiprocessor Bandwidth Inheritance (M-BWI) [13], gEDF-vpr [2], LP-EE-vpr [3], the Multiprocessor resource sharing Protocol (MrsP) [9], the Resource-Oriented Partitioned PCP (ROP-PCP) [18], the Dependency Graph Approach (DGA) for frame-based task set [12], and its extension for periodic task set (HDGA) [25]. These protocols focus on managing the resource accesses and provide real-time guarantees by bounding the worst-case response time of tasks.

The timing analysis of aforementioned protocols are based on the assumption that the implementation overheads are negligible. However, the practice overheads may impact the performance of different protocols according to their settings, such as local or remote execution of critical sections and the tasks’ waiting semantics, i.e., self-suspension or spinning. Under a suspension-based synchronization protocol, tasks that are waiting for access to a shared resource (i.e., the resource is locked by another task) are suspended. This strategy frees the processor so that it can be used by other ready tasks, which exploits the utilization of processor but also increases the context switch overhead due to extra en-queue and de-queue operations for each suspension. Under a spin-based synchronization protocol, the task does not give up its privilege on the processor and has to wait by spinning on the processor until it can access to the requested resource and starts its critical section, which has been shown to be efficient when the critical sections are short [17]. In addition, their performance also highly depends on the underlying multiprocessor scheduling paradigm, i.e., (semi-) partitioned and global schedule. Since most of the resource synchronization protocols are not designed for global schedule, in this paper, we only focus on:

  • Partitioned Schedule: Each task is assigned on a dedicated processor, each processor maintains its own ready queue and scheduler. Tasks are not allowed to migrate among processors, e.g., MPCP.

  • Semi-partitioned Schedule: Unlike the pure partitioned schedule, semi-partitioned schedule allows tasks to migrate to other processors under certain conditions. For example, in DPCP and ROP-PCP, shared resources are assigned on processors, the critical sections have to be executed on the corresponding processors, where may not be the same as the original partition of a task.

Although some of the above protocols are theoretically sound, only a few of them have been implemented on real-time operating systems, e.g., the Linux Testbed for Multiprocessor Scheduling in Real-Time Systems ([10, 6], and Real-Time Executive for Multiprocessor Systems (RTEMS) [1]. In , there are quite a lot of implementations for multiprocessor resource synchronization protocols. Brandenburg et al. implemented DPCP, MPCP, and FMLP [7], Catellani et al. implemented MrsP [11], and Shi et al. solidate the implementation of MrsP [24]. In addition, the recently developed DGA and its extension for periodic tasks HDGA have been implemented by Shi et al. in [22, 23]. However, is an experimental platform for timing analysis instead of a comprehensive operating system for industrial applications.

RTEMS is an open-source and commercially supported operating system, without the burden of running additional system services as Linux-based test-bed in comparison to

. RTEMS has been widely used in many fields, e.g., space flight, medical, networking, etc. However, in RTEMS, only MrsP implemented by Catellani et al. in [11], is officially supported in the upstream repository. Considering the real system overhead, the performance of resource synchronization protocols might be clarified and decidable by system designers. Therefore, it is beneficial to provide comprehensively support on RTEMS with resource synchronization protocols for the related researches.

Our Contribution: In this work, we enhance the upstream version of RTEMS with the aforementioned multiprocessor resource synchronization protocols and discuss how to revise the kernel with RTEMS Symmetric Multiprocessing (SMP) support. We plan to release the patches on Github and commit them to the upstream repository.

  • To harden the open source development, we review the SMP support of RTEMS and point out the potential pitfalls during the implementation, so that the insights can be reused on any other platforms (see Section III).

  • We detail the development of three multiprocessor resource synchronization protocols, i.e., MPCP, DPCP, and FMLP, and their variants in RTEMS (see Section IV).

  • To study the impact of the implementation overheads, we deploy our implementations on a real platform with synthetic task sets (see Section V). The measured overheads show that our implementation overheads are comparable to the existed implementation of MrsP, in RTEMS, which illustrates the applicability of our implementations.

Ii System Model

We consider a task set consists of recurrent tasks to be scheduled on symmetric and identical (homogeneous) processors. All tasks can have multiple (non-nested) critical sections, each critical section accesses one of the shared resources, denoted as Each task is described by a tuple , where:

  • is the worst-case execution time (WCET) of task , i.e., .

  • is the set of resource(s) that requests.

  • is the period of task , i.e., .

  • is the relative deadline of the task . To fulfill its timing requirements a job of released at time must finish its execution before its absolute deadline . We consider constrained-deadline task systems, i.e., for every task .

  • is the priority of task .

rtems_semaphore_obtain

_SEM_Seize

_SEM_Get_owner

owner == NULL

_SEM_Wait_For _ownership

Enqueue task using TQ functions of the semaphore variant

Wait

_SEM_Claim _Ownership

Lock

Y

N
Fig. 1: Workflow of the lock directive. Block and are specified according to the adopted protocols.

Iii Symmetric Multiprocessing Support in RTEMS

RTEMS allows users to implement new resource synchronization protocols by strictly following the RTEMS API. To create a new semaphore, SEM_Initialize function is called to define the specified attributes for each resource synchronization protocol. Besides the creation of semaphore, which is defined by different protocols, some common components that are similar for all the protocols, i.e., lock and unlock directives, configuration for applications, and migration mechanism, are introduced in this section.

Iii-a Lock and Unlock Directives

The workflow of the lock directive is shown in Fig. 1. Once a task requests a shared resource, it will try to lock the corresponding semaphore. After selecting the right semaphore, denoted as SEM, calls the _SEM_Seize function. Then, the ownership of the semaphore is checked by getting the owner of the Thread queue Control. If the semaphore is locked by another task, has to wait for the owner to release the semaphore. The detailed operations in block are specified according to the design of different protocols. If there is no owner yet, will be set as the owner of the semaphore, and starts the execution of its critical section. The operations in block can also be different according to the specified design of protocols.

The workflow of the unlock directive is shown in Fig. 2. It will be called when task has finished the execution of its critical section and releases the lock of the semaphore. The unlock directive selects the right _SEM_Surrender function to check whether the is the current owner of the semaphore. If is not the owner, the semaphore cannot be unlocked. Otherwise, can unlock the semaphore by executing the commands in block . The main function in is to find the next owner for the semaphore if (at least) one task that is waiting for the semaphore. If there is no waiting task, the owner will be set to NULL accordingly. The details of the functions in will be discussed in the corresponding sections for different protocols.

rtems_semaphore _release

_SEM_Surrender

_SEM_Get_owner

owner != executing

Not owner

Unlock

Y

N
Fig. 2: Workflow of the unlock directive. Block is specified according to the adopted protocols.

Iii-B Application Configuration

In order to support semi-partitioned schedule in RTEMS, the flow for configuration in Fig. 3 has to be followed. Firstly, processors have to be bound to specific scheduler instances by using macro _RTEMS_SCHEDULER_ASSIGN supported in RTEMS by default. After that, each task is partitioned to a scheduler instance by using the rtems_task_set_scheduler directive. Each task can only be executed on the processor of the corresponding scheduler instance.

Processor

Scheduler Instance

Tasks

Step 1

Step 2
Fig. 3: The steps to configure

When a RTEMS application is configured with SMP support by following the work flow in Fig. 3, some new functions have to be implemented. In Step 1, an initial task has to be defined, which is executed in the beginning of the RTEMS application. The binding of scheduler instances to processor is based of the guide in the official c-user guide. The dedicated schedule algorithm for the scheduler instances has to be selected at first. In this paper, the Deterministic Priority SMP Scheduler supported in RTEMS by default is selected for all the protocols, which is the same as Fixed-Priority (FP) scheduler in the literature. Please note that, the instances have to be defined for all the available processors in the system, in order to support the semi-partitioned schedule, i.e., tasks may migrate to other processors by changing their scheduler nodes, details can be found in next subsection.

Iii-C Migration Mechanism

The migration mechanism can be achieved by using arbitrary processor affinity in [16] is not supported in the current version of RTEMS. Therefore, a new migration mechanism has to be applied for those distributed-based protocols, e.g., DPCP. In our implementation, the scheduler node is modified during the run time in order to realize the task migration. When a task needs to migrate to another processor, the scheduler node of the task in its original scheduler instance is blocked, and the scheduler node of the task in its destination processor is unblocked. An additional function named _Scheduler_Migrate_To is implemented in schedulerimpl.h, which contains the task information block, the target processor, and the priority of the task in the target processor. In addition, in order to guarantee the correctness of the migration, thread-dispatch is disabled during the migration operation.

Fig. 4 demonstrates an example of the implemented task migration. In Fig. 4 (1), task has a scheduler node for every scheduler instance in the system. is currently executing on CPU#0 with a priority of by using scheduler node , which is indicated by the the node with green background. Other two nodes with grey background are blocked, since has no access to their respective scheduler instances, denoted as dashed line. In Fig. 4 (2), task performs migration to CPU#1. blocks itself on its original scheduler by using the block function of the scheduler instance on . After that, it adds to the list of its active scheduler nodes and modifies the priority of accordingly. It unblocks by using the unblock function of the corresponding scheduler instance. Migrating back to the original processor works similarly, i.e., Fig. 4 (1) is restored by using the same unblock/block function of the scheduler instances.

Task Executing on CPU#0

(255) [CPU#1] BLOCKED

(7) [CPU#0] SCHEDULED

(255) [CPU#2] BLOCKED

Task Migrated to CPU#1

(2) [CPU#1] SCHEDULED

(7) [CPU#0] BLOCKED

(255) [CPU#2] BLOCKED

(1)

(2)
Fig. 4: Scheduler Node management: (1) Before migration, (2) After migration. Dashed blocks and lines represent that has no access to the respective scheduler instances, whereas green block is the currently used one.

Iv Multiprocessor Resource Synchronization

In this section, the implementation details of three protocols and corresponding variants are explained and discussed. Please note, we only consider non-nested resource accesses in our implementation, i.e., only one shared resource is requested during the execution of one critical section.

Iv-a Multiprocessor Priority Ceiling Protocol

The Multiprocessor Priority Ceiling Protocol (MPCP) is a typical protocol that is based on a partitioned fixed priority (P-FP) scheduler. That is, each task has a pre-defined priority, and the execution of a task is bounded on a pre-defined processor, i.e., no migration is allowed. The main features of MPCP are: 1) a task will suspend itself if the resource is not available. 2) if a task is granted to access a shared resource, the priority of the task will be boosted to the ceiling priority, which equals to the highest priority of these tasks that request that resource.

The self-suspension feature is supported in RTEMS by default. In order to implement the ceiling priority boosting, one new semaphore structure is created. Besides these normal components, e.g., semaphore lock, wait queue, and current semaphore owner, one variable named ceiling_priority is added 111Please note, in our implementation the ceiling priority is defined by users instead of being calculated by the system dynamically.. The pseudo code provided in Algo. 1 shows two main functions in our implementation, which fits the lock and unlock directive in Section III-A. The details are as follows: Once a task requests a shared resource, the ownership of the shared resource (semaphore) will be checked. If the owner of the requested shared resource is NULL, becomes the owner, and the priority of is boosted to the ceiling priority on the corresponding scheduler instance (operations in block in Fig. 1). Otherwise, will be added into a wait queue, which is sorted by tasks’ original priorities, i.e., task with higher priority will get earlier position (operations in block in Fig. 1). Once the task finishes the execution of critical section, it will release the semaphore. The first task of the wait queue is checked, i.e., the task with the highest priority in the wait queue. If there is no task in the wait queue, the semaphore owner will be set to NULL. Otherwise, the first task of the wait queue will be set as the semaphore owner (operations in block in Fig. 2).

0:  Task , and ceiling_priority of related semaphore;  Function mpcp_lock():
1:  if semaphore_owner is NULL then
2:     semaphore_owner ;
3:      ceiling_priority;
4:      starts the execution of its critical section;
5:  else
6:     Add to the corresponding wait_queue;
7:  end if Function mpcp_unlock():
8:   releases the semaphore lock;
9:  Next task the head of the wait_queue;
10:  if  is NULL then
11:     semaphore_owner NULL;
12:  else
13:     semaphore_owner ;
14:      starts the execution of its critical section;
15:  end if
Algorithm 1 MPCP implementation

Iv-B Distributed Priority Ceiling Protocol

The Distributed Priority Ceiling Protocol (DPCP) is based on semi-partitioned fixed priority schedule. In DPCP, tasks and shared resources are assigned on different processors independently, i.e., these processors that are assigned for the execution of non-critical sections are called application processors, and processors for the execution of critical sections are called synchronization processors. Once a task tries to access a shared resource, it will migrate to the corresponding synchronization processor where the shared resource is assigned on, before trying to lock the corresponding semaphore. Afterwards, these tasks on the same synchronization processor operate follow the uni-processor PCP, which been supported in RTEMS by default, i.e., Immediate Ceiling Priority Protocol (ICPP). When a task finished its execution of critical section, it will migrate back to the original application processor to continue the execution of its non-critical section, if it exists.

Therefore, the main challenge of the implementation of DPCP is to allow task migrations among processors. In RTEMS, task partitioning is realized by the scheduler node in the scheduler function, i.e., scheduler node defines the original partition for each task before the execution, and stays the same during the run time. Details have been explained in Section III-C.

Iv-C Flexible Multiprocessor Locking Protocol

In Flexible Multiprocessor Locking Protocol (FMLP), requests of shared resources are divided into two groups, i.e., long and short, according to the length of the execution time of corresponding critical section. When the requested resource is not available, a task will suspend itself if it is a long request, and a task will spin on the correspond processor if it is a short request. However, there is no conclusion regarding to how to divide requests to obtain a better schedulability. Therefore, we divided our implementation into FMLP-L which only supports long requests, and FMLP-S which only supports short requests. Please note, to simplify the implementation, all the tasks in one task set all belong to either long group or short group, no mixed division of these two groups is allowed.

In both FMLP-L and FMLP-S, the wait queue in the semaphore structure is in a FIFO order, rather than sorting by priorities like MPCP and DPCP. The operations in block in Fig. 1 are as follows: In FMLP-L, we maintain a ceiling priority dynamically for each resource, which equals to the highest priority of these tasks that are currently waiting for the resource, i.e., tasks in the corresponding wait queue. The priority of the semaphore owner will be boosted to the ceiling priority if the original priority is lower than the ceiling priority, when it starts the execution of its critical section. In FMLP-S, the owner of the semaphore gets priority boosted to the highest possible priority in the system, so that the execution of its critical section is the non-preemptive. The operations in block in Fig. 1 are the same for both FMLP-L and FMLP-S, i.e., add task in the end of the corresponding wait queue. The unlock operations in block in Fig. 2 are also the same, i.e., try to find the next owner for the semaphore by checking the first task in the wait queue, if it exists.

Additionally, we implemented a distributed version of FMLP, denoted as DFLP, where all the requests are treated as long requests. The main difference between FMLP and DFLP is when a task requests a shared resource, it will migrate to the corresponding synchronization processor, which is similar to DPCP. The mechanism how we implement the migration has been explained in Section III-C. After the migration, critical sections are executed by following the FMLP-L on the corresponding synchronization processor(s).

V Evaluation and Discussion

In this section, we introduce the setup of experiments for overheads evaluation at first. Afterwards, the measured overheads are reported and analyzed. At the end, we discuss the need of formal verification over the implementation generally.

V-a Experimental Setup

We evaluated the overheads of our implementations on the following platform: a NXP QorIQ T4240 RDB reference design board, which is the same as used in [11]. It has 6 GB DDR3 memory with 1866 MT/s data rate, 128 MB NOR flash(16-bit), and 2 GB SLC NAND flash. The processor T4240 contains 24-virtual-core (12 physical cores) with the PowerPC Architecture, and is running on 1.67 GHz.

To measure the overheads of our implemented protocols, timestamps are added before and after the function of our implementations. The obtain and release functions of the semaphore are measured, denoted as lock and unlock respectively. We consider a multi-processor system consists of four processors, i.e., , including three application processors and one synchronization processor. The total number of tasks , and the number of available shared resources , i.e., . On each application processor, there are five tasks with five different priority levels, i.e., {High (H), Medium-High (MH), Medium (M), Medium-Low (ML) and Low (L)}. Each task requests one of these three shared resources. Details can be found in Table I.

CPU#0
Application
CPU#1
Application
CPU#2
Application
CPU#3
Synchronization
L () L () L () -
ML () ML () ML () -
M () M () M () -
MH () MH () MH () -
H () H () H () -
TABLE I: Processor allocation of the test application.
Fig. 5: Overheads of protocols in RTEMS (lock operation is ended by _lk and unlock operation is ended by _ulkl)). The measurement of migrating a task to the synchronization processor (denoted as mig_to) and back to the application processor (denoted as mig_bk).

V-B Overheads Evaluation

The overheads for different protocols are reported in Figure 5, based on more than 9,000 instances of lock and unlock operations. These distributed based protocols, i.e., DPCP and DFLP have higher overheads than others, because of the task migrations, i.e., a task migrates to the synchronization processor to execute its critical section and back to the application processor when it finishes the execution of critical section. DFLP has the highest average overheads, since it also maintains the dynamic ceiling priority update. MrsP also has relative high overheads, since it has the help mechanism requiring task migration (however, help mechanism may not be activated all the time). Our results related to MrsP are similar as reported in [11], i.e., 5376 ns for lock and 5514 ns for unlock on average. FMLP-L has the lowest overheads, due to the simplest mechanism. Overall, the overheads for all the protocols are relatively low and acceptable.

The migration overheads are measured separately, and reported in the left side of Figure 5. The results show that the overheads of task migration are significant, which might substantially affect those distributed-base protocols, i.e., DPCP and DFLP. Interestingly, we also notice that the overhead of a task to migrate to the synchronization processor is faster than migrating back to the application processor. The reason is that, normally there are more tasks running on the application processors than synchronization processors, which causes a task has to wait for longer time to obtain the scheduler instance lock on average. That is why the unlock overheads of DPCP and DFLP are higher than the lock overheads.

V-C Validation and Formal Verification

To validate the correctness of our implementation, at first we test over the official coverage tests provided by RTEMS, i.e., the SMP test suites222https://github.com/RTEMS/rtems/tree/master/testsuites/smptests especially, on the PowerPC device and also the QEMU emulator for ARM RealView Platform realview-pbx-a9, and conclude that the SMP related peripheries in RTEMS are not affected at all. Moreover, we further design several dedicated corner cases for each protocol and ensure that the designated tasks execute as the expected behaviors, which are treated as the additional coverage test for the future integration.

We note that such case-based validation may not be sufficient, since it is not possible to test over every case exhaustively. One possible way is to adopt software model checkers as proposed in  [14] to detect potential data races and deadlocks in the implementation of PIP with nested locks in RTEMS. However, such searching approaches may not scale well for multiprocessor protocols unless an effective pruning strategy can be found beforehand. How to validate or formally verify an existing implementation of synchronization protocols is still an unsolved problem but out of the scope.

Vi Conclusion

Over the decades, quite a few number of resource synchronization protocols have been extensively studied for uni-processor and especially multiprocessor real-time systems. In this work, we reviewed the SMP support in one popular real-time operating system RTEMS and detailed how we develop three state-of-the-art multiprocessor resource synchronization protocols, i.e., MPCP, DPCP, and FMLP, and their variants. With extensive synthetic experiments, the measured results showed that our implementations are comparable to MrsP, which is officially supported in RTEMS.

All the mentioned details will be released on Github as patches, which are compatible with the upstream repository. Although several dedicated tests are provided to verify the correctness of the implementation, formal model checking is still desirable to prevent the system from potential deadlock, data races, and priority inversions. In the future work, we plan to explore on nested resource synchronization and support the arbitrary processor affinity in RTEMS to improve the generality and the efficiency.

References

  • [1] Real-Time Executive for Multiprocessor Systems. http://www.rtems.org/. visit on 15.04.2020.
  • [2] B. Andersson and A. Easwaran. Provably good multiprocessor scheduling with resource sharing. Real-Time Systems, 46(2):153–159, 2010.
  • [3] B. Andersson and G. Raravi. Real-time scheduling with resource sharing on heterogeneous multiprocessors. Real-Time Systems, 50(2):270–314, 2014.
  • [4] T. P. Baker. Stack-based scheduling of realtime processes. Real-Time Systems, 3(1):67–99, 1991.
  • [5] A. Block, H. Leontyev, B. Brandenburg, and J. Anderson. A flexible real-time locking protocol for multiprocessors. In RTCSA, pages 47–56, 2007.
  • [6] B. Brandenburg. Scheduling and Locking in Multiprocessor Real-Time Operating Systems. PhD thesis, The University of North Carolina at Chapel Hill, 2011.
  • [7] B. B. Brandenburg and J. H. Anderson. An implementation of the pcp, srp, d-pcp, m-pcp, and fmlp real-time synchronization protocols in litmus^ rt. In Embedded and Real-Time Computing Systems and Applications. RTCSA 2008. 14th IEEE International Conference on, pages 185–194. IEEE.
  • [8] B. B. Brandenburg and J. H. Anderson. Optimality results for multiprocessor real-time locking. In Real-Time Systems Symposium (RTSS), pages 49–60, 2010.
  • [9] A. Burns and A. J. Wellings. A schedulability compatible multiprocessor resource sharing protocol - MrsP. In Euromicro Conference on Real-Time Systems (ECRTS), pages 282–291, 2013.
  • [10] J. M. Calandrino, H. Leontyev, A. Block, U. C. Devi, and J. H. Anderson. LITMUS: A testbed for empirically comparing real-time multiprocessor schedulers. In Real-Time Systems Symposium (RTSS), pages 111–126. IEEE, 2006.
  • [11] S. Catellani, L. Bonato, S. Huber, and E. Mezzetti. Challenges in the implementation of mrsp. In Reliable Software Technologies - Ada-Europe 2015 - 20th Ada-Europe International Conference on Reliable Software Technologies, Madrid Spain, June 22-26, 2015, Proceedings, pages 179–195, 2015.
  • [12] J.-J. Chen, G. von der Brüggen, J. Shi, and N. Ueter. Dependency graph approach for multiprocessor real-time synchronization. In IEEE Real-Time Systems Symposium, RTSS, pages 434–446, 2018.
  • [13] D. Faggioli, G. Lipari, and T. Cucinotta. The multiprocessor bandwidth inheritance protocol. In Euromicro Conference on Real-Time Systems, pages 90–99, 2010.
  • [14] S. Gadia, C. Artho, and G. Bloom. Verifying nested lock priority inheritance in RTEMS with java pathfinder. In K. Ogata, M. Lawford, and S. Liu, editors, Formal Methods and Software Engineering - 18th International Conference on Formal Engineering Methods, 2016, Tokyo, Japan, November 14-18, 2016, Proceedings, volume 10009 of Lecture Notes in Computer Science, pages 417–432, 2016.
  • [15] P. Gai, G. Lipari, and M. D. Natale. Minimizing memory utilization of real-time task sets in single and multi-processor systems-on-a-chip. In Real-Time Systems Symposium (RTSS), pages 73–83, 2001.
  • [16] A. Gujarati, F. Cerqueira, and B. B. Brandenburg. Multiprocessor real-time scheduling with arbitrary processor affinities: from practice to theory. Real-Time Systems, 51(4):440–483, 2015.
  • [17] G. Han, H. Zeng, M. Natale, X. Liu, and W. Dou. Experimental evaluation and selection of data consistency mechanisms for hard real-time applications on multicore platforms. IEEE Transactions on Industrial Informatics, 10(2):903–918, 2014.
  • [18] W.-H. Huang, M. Yang, and J.-J. Chen. Resource-oriented partitioned scheduling in multiprocessor systems: How to partition and how to share? In Real-Time Systems Symposium (RTSS), pages 111–122, 2016.
  • [19] R. Rajkumar. Real-time synchronization protocols for shared memory multiprocessors. In Proceedings.,10th International Conference on Distributed Computing Systems, pages 116 – 123, 1990.
  • [20] R. Rajkumar, L. Sha, and J. P. Lehoczky. Real-time synchronization protocols for multiprocessors. In Proceedings of the 9th IEEE Real-Time Systems Symposium (RTSS ’88), pages 259–269, 1988.
  • [21] L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority inheritance protocols: An approach to real-time synchronization. IEEE Trans. Computers, 39(9):1175–1185, 1990.
  • [22] J. Shi. DGA-LITMUS-RT. https://github.com/Strange369/Dependency-Graph-Approaches-for-LITMUS-RT, 2018.
  • [23] J. Shi. HDGA-LITMUS-RT. https://github.com/Strange369/Dependency-Graph-Approach-for-Periodic-Tasks, 2019.
  • [24] J. Shi, K.-H. Chen, S. Zhao, W.-H. Huang, J.-J. Chen, and A. Wellings. Implementation and evaluation of multiprocessor resource synchronization protocol (mrsp) on litmusrt. In 13th Workshop on Operating Systems Platforms for Embedded Real-Time Applications, 2017.
  • [25] J. Shi, N. Ueter, G. von der Brüggen, and J.-j. Chen. Multiprocessor synchronization of periodic real-time tasks using dependency graphs. In 2019 IEEE Real-Time and Embedded Technology and Applications Symposium, pages 279–292, 2019.