{"title":"Process Barrier for Predictable and Repeatable Concurrent Execution","authors":"Masataka Nishi","doi":"10.1145/3303084.3309494","DOIUrl":null,"url":null,"abstract":"We study on how to design, debug and verify and validate (V&V) safety-critical control software running on shared-memory many-core platforms. Managing concurrency in a verifiable way is a certification requirement. The presented process barrier is a simple concurrency control mechanism that guarantees deadlock-freedom by-design and temporal separation of tasks, while allowing non-conflicting tasks to run in parallel. It is placed in a lock-free task queue (LFTQ) and a group of processors are allocated to compete to dequeue and execute the tasks registered in the LFTQ. The process barrier consists of a checker and limiter pair. A process that dequeues the checker monitors for completion of preceding tasks in the LFTQ that conflicts with a subsequent task in the LFTQ. The process dequeues the paired limiter from the LFTQ upon completion. All other processes that find the limiter at the head of the LFTQ periodically checks if the head of the LFTQ points to subsequent tasks which happens after the process that took the checker task dequeues the limiter. The mechanism manages concurrent execution of the registered tasks that conflict on data, shared resources and execution order in a way that becomes conflict equivalent to sequential execution. The trace of the concurrent execution and the consequent program state is repeatable. We can reuse existing toolchains for single-core platforms for debugging, testing and V&V. The temporal behavior of the concurrent execution becomes predictable and the worst-case execution time (WCET) of it is bounded.","PeriodicalId":408167,"journal":{"name":"Proceedings of the 10th International Workshop on Programming Models and Applications for Multicores and Manycores","volume":"38 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2019-02-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the 10th International Workshop on Programming Models and Applications for Multicores and Manycores","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/3303084.3309494","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0
Abstract
We study on how to design, debug and verify and validate (V&V) safety-critical control software running on shared-memory many-core platforms. Managing concurrency in a verifiable way is a certification requirement. The presented process barrier is a simple concurrency control mechanism that guarantees deadlock-freedom by-design and temporal separation of tasks, while allowing non-conflicting tasks to run in parallel. It is placed in a lock-free task queue (LFTQ) and a group of processors are allocated to compete to dequeue and execute the tasks registered in the LFTQ. The process barrier consists of a checker and limiter pair. A process that dequeues the checker monitors for completion of preceding tasks in the LFTQ that conflicts with a subsequent task in the LFTQ. The process dequeues the paired limiter from the LFTQ upon completion. All other processes that find the limiter at the head of the LFTQ periodically checks if the head of the LFTQ points to subsequent tasks which happens after the process that took the checker task dequeues the limiter. The mechanism manages concurrent execution of the registered tasks that conflict on data, shared resources and execution order in a way that becomes conflict equivalent to sequential execution. The trace of the concurrent execution and the consequent program state is repeatable. We can reuse existing toolchains for single-core platforms for debugging, testing and V&V. The temporal behavior of the concurrent execution becomes predictable and the worst-case execution time (WCET) of it is bounded.