llvm-capstone/libcxx/www/atomic_design.html
xgupta 94fac81fcc [Branch-Rename] Fix some links
According to the [[ https://foundation.llvm.org/docs/branch-rename/ | status of branch rename ]], the master branch of the LLVM repository is removed on 28 Jan 2021.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D95766
2021-02-01 16:43:21 +05:30

92 lines
2.5 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>&lt;atomic&gt; design</title>
<link type="text/css" rel="stylesheet" href="menu.css">
<link type="text/css" rel="stylesheet" href="content.css">
</head>
<body>
<div id="menu">
<div>
<a href="https://llvm.org/">LLVM Home</a>
</div>
<div class="submenu">
<label>libc++ Info</label>
<a href="/index.html">About</a>
</div>
<div class="submenu">
<label>Quick Links</label>
<a href="https://lists.llvm.org/mailman/listinfo/cfe-dev">cfe-dev</a>
<a href="https://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits</a>
<a href="https://bugs.llvm.org/">Bug Reports</a>
<a href="https://github.com/llvm/llvm-project/tree/main/libcxx/">Browse Sources</a>
</div>
</div>
<div id="content">
<!--*********************************************************************-->
<h1>&lt;atomic&gt; design</h1>
<!--*********************************************************************-->
<p>
There are currently 3 designs under consideration. They differ in where most
of the implementation work is done. The functionality exposed to the customer
should be identical (and conforming) for all three designs.
</p>
<ol type="A">
<li>
<a href="atomic_design_a.html">Minimal work for the library</a>
</li>
<li>
<a href="atomic_design_b.html">Something in between</a>
</li>
<li>
<a href="atomic_design_c.html">Minimal work for the front end</a>
</li>
</ol>
<p>
With any design, the (back end) compiler writer should note:
</p>
<blockquote>
<p>
The decision to implement lock-free operations on any given type (or not) is an
ABI-binding decision. One can not change from treating a type as not lock free,
to lock free (or vice-versa) without breaking your ABI.
</p>
<p>
Example:
</p>
<blockquote><pre>
TU1.cc
-----------
extern atomic&lt;long long&gt; A;
int foo() { return A.compare_exchange_strong(w, x); }
TU2.cc
-----------
extern atomic&lt;long long&gt; A;
void bar() { return A.compare_exchange_strong(y, z); }
</pre></blockquote>
</blockquote>
<p>
If only <em>one</em> of these calls to <tt>compare_exchange_strong</tt> is
implemented with mutex-locked code, then that mutex-locked code will not be
executed mutually exclusively of the one implemented in a lock-free manner.
</p>
</div>
</body>
</html>