Resource sharing in RTSJ and SCJ systems

Wellings, Andy; Lin, Shiyao; Burns, Alan

doi:10.1145/2043910.2043913

Cited by 5 publications

(3 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…An overview of different approaches of locking on multicore versions of RTSJ and SCJ systems is given by Wellings et al . They find that to bound blocking and prevent deadlocks, threads holding global locks should be nonpreemptible on both fully partitioned and clustered systems, corresponding to an SCJ level 1 and level 2 implementation, respectively. All nested locking should be refactored to follow FMLP or some other protocol that ensures access ordering.…”

Section: Background and Related Workmentioning

confidence: 99%

“…All nested locking should be refactored to follow FMLP or some other protocol that ensures access ordering. Wellings et al note that FMLP introduces group locks, which have the side effect of reducing parallelism. Any application developer wishing to use RTSJ or SCJ for predictability must identify global locks and set the locks' ceiling higher than all threads on all processors where the shared lock is reachable.…”

Section: Background and Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Hardware locks for a real‐time Java chip multiprocessor

Strøm

Puffitsch

Schoeberl

2016

Concurrency and Computation

View full text Add to dashboard Cite

A software locking mechanism commonly protects shared resources for multithreaded applications. This mechanism can, especially in chip-multiprocessor systems, result in a large synchronization overhead. For real-time systems in particular, this overhead increases the worst-case execution time and may void a task set's schedulability. This paper presents 2 hardware locking mechanisms to reduce the worst-case time required to acquire and release synchronization locks. These solutions are implemented for the chipmultiprocessor version of the Java Optimized Processor. The 2 hardware locking mechanisms are compared with a software locking solution as well as the original locking system of the processor. The hardware cost and performance are evaluated for all presented locking mechanisms. The performance of the betterperforming hardware locks is comparable with that of the original single global lock when contending for the same lock. When several noncontending locks are used, the hardware locks enable true concurrency for critical sections. Benchmarks show that using the hardware locks yields performance ranging from no worse than the original locks to more than twice their best performance. This improvement can allow a larger number of real-time tasks to be reliably scheduled on a multiprocessor real-time platform.

show abstract

Section: Background and Related Workmentioning

confidence: 99%

Section: Background and Related Workmentioning

confidence: 99%

Hardware locks for a real‐time Java chip multiprocessor

Strøm

Puffitsch

Schoeberl

2016

Concurrency and Computation

View full text Add to dashboard Cite

show abstract

“…An overview of different approaches of locking on multicore versions of RTSJ and SCJ systems is given in [26]. They find that to bound blocking and prevent deadlocks, threads holding global locks should be non-preemptible on both fully partitioned and clustered systems, corresponding to a SCJ level 1 and level 2 implementation, respectively.…”

Section: Multicore Synchronizationmentioning

confidence: 99%

Chip-multiprocessor hardware locks for safety-critical Java

Strøm

Puffitsch

Schoeberl

2013

Proceedings of the 11th International Workshop on Java Technologies for Real-Time and Embedded Systems

View full text Add to dashboard Cite

Accessing shared resources in multicore systems is usually protected by a software locking mechanism, which itself is implemented through atomic operations. This can result in a large synchronization overhead, which, in the context of real-time systems, increases the worst-case execution time and may void a task set's schedulability. In this paper we present a hardware locking mechanism to reduce the synchronization overhead. The solution is implemented for the chip-multiprocessor version of the Java Optimized Processor in the context of safety-critical Java. The implementation is compared to a software solution. The performance and the hardware cost are evaluated.

show abstract

Multiprocessor Real-Time Locking Protocols

Brandenburg

2022

Handbook of Real-Time Computing

View full text Add to dashboard Cite

Resource sharing in RTSJ and SCJ systems

Cited by 5 publications

References 11 publications

Hardware locks for a real‐time Java chip multiprocessor

Hardware locks for a real‐time Java chip multiprocessor

Chip-multiprocessor hardware locks for safety-critical Java

Multiprocessor Real-Time Locking Protocols

Contact Info

Product

Resources

About