Hardware locks for a real‐time Java chip multiprocessor

Strøm, Tórur Biskopstø; Puffitsch, Wolfgang; Schoeberl, Martin

doi:10.1002/cpe.3950

Cited by 7 publications

(3 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Benchmarks show that this new unit performs at least as well as the global lock and, in the case of heavy lock contention or large noncontending critical sections, far better .…”

Section: Hardware Supportmentioning

confidence: 96%

Safety‐critical Java for embedded systems

Schoeberl

Dalsgaard

Hansen

et al. 2016

Concurrency and Computation

Self Cite

View full text Add to dashboard Cite

Phone +45 4525 3351 compute@compute.dtu.dk www.compute.dtu.dk IMM-PhD-2014-340 Summary (English) Safety-critical systems are real-time systems whose failure can have severe or catastrophic consequences, possibly endangering human life. Many safety-critical systems incorporate embedded computers used to control different tasks. Software running on safety-critical systems needs to be certified before its deployment and the most time-consuming step of this process is the testing and verification phase. Due to the increasing complexity in safety-critical systems there is a need for new technologies that can facilitate testing and verification activities.The safety-critical specification for Java aims at providing a reduced set of the Java programming language that can be used for systems that need to be certified at the highest levels of criticality. Safety-critical Java (SCJ) restricts how a developer can structure an application by providing a specific programming model and by restricting the set of methods and libraries that can be used. Furthermore, its memory model do not use a garbage-collected heap but scoped memories.In this thesis we examine the use of the SCJ specification through an implementation in a time-predictable, FPGA-based Java processor. The specification is now in a mature state and with our implementation we have proved its feasibility in an embedded platform. Moreover, we have explored how simple hardware extensions can reduce the execution time of time-critical operations required by the SCJ specification.The scoped memory model used in SCJ is perhaps one of its most difficult features to use correctly. Therefore, in this work we have also studied practical aspects of its usage by developing scoped memory use patterns and reusable libraries aiming at facilitating the development of complex software systems.ii Summary (Danish)Sikkerhedskritiske systemer er realtidssystemer. Hvis sådanne systemer fejler, kan det have alvorlige eller katastrofale konsekvenser, muligvis livsfarlige konsekvenser. Mange sikkerhedskritiske systemer inkorporerer embeddede computere, som bruges til at kontrollere forskellige opgaver. Software, som kører på sikkerhedskritiske systemer, skal certificeres, før softwaren udrulles, og det mest tidskraevende skridt i denne proces er test-og verifikationsfasen. På grund af den stigende kompleksitet i sikkerhedskritiske systemer er der behov for nye teknologier til at facilitere test-og verifikationsaktiviteter.Den sikkerhedskritiske specifikation for Java har til formål at levere en reduceret udgave af Java-programmeringssproget, som kan bruges til systemer, der skal kunne certificeres på de højeste kritikalitetsniveauer. Safety Critical Java (SCJ) begraenser, hvordan en udvikler kan strukturere en applikation, ved at levere en specifik programmeringsmodel og ved at begraense de metoder og biblioteker, som kan anvendes. Derudover benytter hukommelsesmodellen i SCJ ikke en heap, der er garbage-collected, men afgraensede hukommelser.I denne afhandling undersøger vi brugen a...

show abstract

“…Benchmarks show that this new unit performs at least as well as the global lock and, in the case of heavy lock contention or large noncontending critical sections, far better .…”

Section: Hardware Supportmentioning

confidence: 96%

Safety‐critical Java for embedded systems

Schoeberl

Dalsgaard

Hansen

et al. 2016

Concurrency and Computation

Self Cite

View full text Add to dashboard Cite

show abstract

“…In our previous work [14] we implement hardware locks for a Java processor that support queues of waiting tasks. The locks support 3 types of atomic operations: requesting a lock, checking ownership, and releasing a lock.…”

Section: Related Workmentioning

confidence: 99%

Hardlock: A Concurrent Real-Time Multicore Locking Unit

Strøm

Schoeberl

2018

2018 IEEE 21st International Symposium on Real-Time Distributed Computing (ISORC)

Self Cite

View full text Add to dashboard Cite

To use multicore processors, an application needs to split computation into several threads that execute on different processing cores. As those threads work together towards a common goal, they need to exchange data in a controlled way. A common communication paradigm between cooperating threads is using shared data structures protected by locks. Implementing a lock on top of shared memory can easily result in a bottleneck on a multicore processor due to the congestion on the shared memory. However, the number of locks in use is usually low and using the large external memory to support locks is over-provisioning a resource. This paper presents an efficient implementation of locking by providing dedicated hardware support for locking on-chip. This locking unit supports a restricted number of locks without the need to get off-chip. The unit can process lock acquisitions in 2 clock cycles and releases in 1 clock cycle.

show abstract

“…The first paper discusses software locking mechanisms that commonly protect shared resources for multithreaded applications. This mechanism can, especially in chip‐multiprocessor systems, result in a large synchronization overhead.…”

mentioning

confidence: 99%

Java Technologies for Real‐Time and Embedded Systems (JTRES2013)

Fox

2017

Concurrency and Computation

View full text Add to dashboard Cite

This outline describes a special issue of papers from the 2013 workshop on Java Technologies for Real-Time and Embedded Systems [1]. There are 2 papers in this special issue.The first paper [2] discusses software locking mechanisms that commonly protect 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 chip-multiprocessor 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 better performing hardware locks is comparable to 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.Safety Critical Java (SCJ) is a profile of the Real-Time Specification for Java that brings to the safety-critical industry the possibility of using Java. Safety Critical Java defines 3 compliance levels: Level 0, Level 1, and Level 2. The SCJ specification is clear on what constitutes a Level 2 application in its use of the defined API but not the occasions on which it should be used. The second paper [3] broadly classifies the features that are only available at Level 2 into 3 groups: nested mission sequencers, managed threads, and global scheduling across multiple processors. It then explores the first 2 groups to elicit programming requirements that they support. The paper identifies several areas where the SCJ specification needs modifications to support these requirements fully; these include support for terminating managed threads, the ability to set a deadline on the transition between missions, and augmentation of the mission sequencer concept to support composability of timing constraints. The paper also proposes simplifications to the termination protocol of missions and their mission sequencers. To illustrate the benefit of our changes, the paper presents excerpts from a formal model of SCJ Level 2 written in Circus, a staterich process algebra for refinement.We thank Kelvin Nilsen and Fridtjof Siebert for their work on this special issue.

show abstract

Hardware locks for a real‐time Java chip multiprocessor

Cited by 7 publications

References 33 publications

Safety‐critical Java for embedded systems

Safety‐critical Java for embedded systems

Hardlock: A Concurrent Real-Time Multicore Locking Unit

Java Technologies for Real‐Time and Embedded Systems (JTRES2013)

Contact Info

Product

Resources

About