imported>Rublov: /* History and significance */ MOS

2024-08-25T15:51:25Z

History and significance: MOS

New page

{{Short description|Interactions of threads through memory}}
{{about|a concept in multi-thread programming|details of memory addressing|Memory address#Memory models}}

In computing, a '''memory model''' describes the interactions of [[Thread (computer science)|threads]] through [[memory (computing)|memory]] and their shared use of the [[data (computing)|data]].

==History and significance==
A memory model allows a compiler to perform many important optimizations. [[Compiler optimization]]s like [[loop fusion]] move statements in the program, which can influence the order of read and write operations of potentially shared [[variable (programming)|variables]]. Changes in the ordering of reads and writes can cause [[race condition]]s. Without a memory model, a compiler may not apply such optimizations to multi-threaded programs at all, or it may apply optimizations that are incompatible with multi-threading, leading to bugs.

Modern programming languages like [[Java (programming language)|Java]] therefore implement a memory model. The memory model specifies [[synchronization barrier]]s that are established via special, well-defined synchronization operations such as acquiring a lock by entering a synchronized block or method. The memory model stipulates that changes to the values of shared variables only need to be made visible to other threads when such a synchronization barrier is reached. Moreover, the entire notion of a [[race condition]] is defined over the order of operations with respect to these memory barriers.<ref>{{cite web
| url=http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
| title=JSR 133 (Java Memory Model) FAQ
| author=[[Jeremy Manson]] and [[Brian Goetz]]
| quote=The Java Memory Model describes what behaviors are legal in multithreaded code, and how threads may interact through memory. It describes the relationship between variables in a program and the low-level details of storing and retrieving them to and from memory or registers in a real computer system. It does this in a way that can be implemented correctly using a wide variety of hardware and a wide variety of compiler optimizations.
| date=February 2004
| access-date=2010-10-18}}</ref>

These semantics then give optimizing compilers a higher degree of freedom when applying optimizations: the compiler needs to make sure {{em|only}} that the values of (potentially shared) variables at synchronization barriers are guaranteed to be the same in both the optimized and unoptimized code. In particular, reordering statements in a block of code that contains no synchronization barrier is assumed to be safe by the compiler.

Most research in the area of memory models revolves around:

* Designing a memory model that allows a maximal degree of freedom for compiler optimizations while still giving sufficient guarantees about race-free and (perhaps more importantly) race-containing programs.
* Proving [[program optimization]]s that are correct with respect to such a memory model.

The [[Java memory model]] was the first attempt to provide a comprehensive threading memory model for a popular programming language.<ref>{{cite web
| url=http://www.ibm.com/developerworks/library/j-jtp02244.html
| title=Fixing the Java Memory Model, Part 1
| date=2004-02-24
| last=Goetz|first=Brian
| website=[[IBM]]
| access-date=2008-02-17}}</ref> After it was established that threads could not be implemented safely as a [[Library (computing)|library]] without placing certain restrictions on the implementation and, in particular, that the [[C (programming language)|C]] and [[C++]] standards ([[C99]] and [[C++03]]) lacked necessary restrictions,<ref>{{Cite journal|url = http://plg.uwaterloo.ca/usystem/pub/uSystem/LibraryApproach.pdf
|title = Are Safe Concurrency Libraries Possible?
|journal = Communications of the ACM
|last = Buhr
|first = Peter A.
|date = September 11, 1995
|access-date = 2015-05-12}}</ref><ref>{{Cite web|title = Threads Cannot be Implemented as a Library|url = http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf|access-date = 2015-05-12|last = Boehm|first = Hans-J.|date = November 12, 2004|archive-date = 2017-05-30|archive-url = https://web.archive.org/web/20170530160703/http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf|url-status = dead}}</ref> the C++ threading subcommittee set to work on suitable memory model; in 2005, they submitted C working document n1131<ref>{{Cite web|title = Implications of C++ Memory Model Discussions on the C Language|url = http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1131.pdf|website = www.open-std.org|access-date = 2015-05-12|date = 2005-08-26|last1 = Boehm|first1 = Hans|author-link = Hans-J. Boehm|last2 = Lea|first2 = Doug|author-link2 = Doug Lea|last3 = Pugh|first3 = Bill}}</ref> to get the C Committee on board with their efforts. The final revision of the proposed memory model, C++ n2429,<ref>{{Cite web|title = WG21/N2429: Concurrency memory model (final revision)|url = http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm|website = www.open-std.org|access-date = 2015-05-12|date = 2007-10-05}}</ref> was accepted into the C++ draft standard at the October 2007 meeting in Kona.<ref>{{Cite web|title = N2480: A Less Formal Explanation of the Proposed C++ Concurrency Memory Model|url = http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2480.html|website = www.open-std.org|access-date = 2015-05-12}}</ref> The memory model was then included in the next C++ and C standards, [[C++11]] and [[C11 (C standard revision)|C11]].<ref>{{cite web
| url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1777.pdf
| title=Memory Model for Multithreaded C++: Issues
| date=2005-03-04
| last1=Alexandrescu|first1=Andrei
| last2=Boehm|first2=Hans
| last3=Henney|first3=Kevlin
| last4=Hutchings|first4=Ben
| last5=Lea|first5=Doug
| last6=Pugh|first6=Bill
| quote=C++ threading libraries are in the awkward situation of specifying (implicitly or explicitly) an extended memory model for C++ in order to specify program execution.We propose integrating a memory model suitable for multithreaded execution into the C++ Standard.
| access-date=2014-04-24}}</ref><ref>{{cite web
| url=http://www.hboehm.info/c++mm/
| title=Threads and memory model for C++
| last=Boehm|first=Hans
| access-date=2014-04-24
| quote=This [link farm] provides information related to the effort to clarify the meaning of multi-threaded C++ programs, and to provide some standard thread-related APIs where those are currently missing.}}</ref> The [[Rust (programming language)|Rust programming language]] inherited most of C/C++'s memory model.<ref>{{cite web
| url=https://doc.rust-lang.org/nomicon/atomics.html
| title=The Rustonomicon, Atomics
| quote=Rust pretty blatantly just inherits the memory model for atomics from C++20.
| access-date=2024-07-08}}</ref>

==See also==
*[[Memory ordering]]
*[[Memory barrier]]
*[[Consistency model]]
*[[Shared memory (interprocess communication)]]

==References==
{{reflist|2}}

[[Category:Computer memory]]
[[Category:Consistency models]]
[[Category:Compiler construction]]
[[Category:Programming language design]]
[[Category:Run-time systems]]
[[Category:Concurrency (computer science)]]

{{compu-prog-stub}}

Memory model (programming) - Revision history

imported>Rublov: /* History and significance */ MOS