{'fraction_non_alphanumeric': 0.01789549033643522, 'fraction_numerical': 0.0014316392269148174, 'mean_word_length': 5.688995215311005, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Multiprocessor Priority Ceiling Emulation for Safety-Critical Java

Priority ceiling emulation has preferable properties on uniprocessor systems, such as avoiding priority inversion and being deadlock free. This has made it a popular locking protocol. According to the safety-critical Java specification, priority ceiling emulation is a requirement for implementations. However, implementing the protocol for multiprocessor systems is more complex so implementations might perform worse than non-preemptive implementations. In this paper we compare two multiprocessor lock implementations with hardware support for the Java optimized processor: non-preemptive locking and priority ceiling emulation. For the evaluation we analyze the worst-case execution time of the locking routines. We also analyze a safety-critical use case with each implementation. We find that the additional software steps necessary for managing priorities in priority ceiling emulation increase the number of locking cycles by at least a factor 15, mainly due to memory contention in a multiprocessor system. This overhead results in the use case being unschedulable using priority ceiling emulation. Any benefits of priority ceiling emulation are also lost when the tasks are completely distributed among the processor. Therefore, given distributed tasks with short critical sections, non-preemptive locking is preferred.