www/atomic_design.html


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

<!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://llvm.org/svn/llvm-project/libcxx/trunk/">Browse SVN</a>
    <a href="https://llvm.org/viewvc/llvm-project/libcxx/trunk/">Browse ViewVC</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>