Abstract
Concurrent programs have behaviors, which cannot be explained by interleaving execution of their threads on a single processing unit due to optimizations, which are performed by modern compilers and CPUs. How to correctly and completely define a semantics of a programming language, which accounts for the behaviors, is an open research problem. There is an auspicious attempt to solve the problem - promising memory model. To show that the model might be used as a part of an industrial language standard, it is necessary to prove correctness of compilation from the model to memory models of target processor architectures. In this paper, we present a proof of compilation correctness from a subset of promising memory model to an axiomatic ARMv8.3 memory model. The subset contains relaxed memory accesses and release and acquire fences. The proof is based on a novel approach of an execution graph traversal.
Highlights
Concurrent programs have behaviors, which cannot be explained by interleaving execution of their threads on a single processing unit due to optimizations, which are performed by modern compilers and CPUs
How to correctly and completely define a semantics of a programming language, which accounts for the behaviors, is an open research problem
To show that the model might be used as a part of an industrial language standard, it is necessary to prove correctness of compilation from the model to memory models of target processor architectures
Summary
В этом разделе мы, аналогично разделу 3, рассмотрим обещающую модель памяти на примере программы LB, а также на двух вариациях этой программы, которые содержат барьеры памяти. Как левый поток обещает сделать запись , соответствующее сообщение добавляется во множество обещаний, еще не выполненных левым потоком, а также в память. Как и в случае модели ARMv8.3, для того, чтобы запретить результат (a = 1, b = 1), в программу могут быть добавлены барьеры памяти. При эффективной компиляции программы из синтаксиса обещающей модели в синтаксис ARMv8 высвобождающий барьер переходит в полный барьер памяти ARMv8, а приобретающий – в барьер по чтению. [x] := 1; Несмотря на то, что после компиляции данная программа не может иметь слабое поведение (a = 1, b = 1), сама программа LB-ACQ в рамках обещающей модели имеет данное поведение. При компиляции высвобождающие барьеры переходят в полные барьеры, которые так же, как и барьеры по чтению, гарантируют отсутствие слабого поведения для соответствующей программы в рамках модели ARMv8.3
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callMore From: Proceedings of the Institute for System Programming of the RAS
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
