blob: 30fb6feeb0d3243884da683b093ffe74a7724a35 [file] [log] [blame]
Howard Hinnant56f0d5b2010-10-05 16:44:401<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
3<!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ -->
4<html>
5<head>
6 <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
7 <title>&lt;atomic&gt; design</title>
8 <link type="text/css" rel="stylesheet" href="menu.css">
9 <link type="text/css" rel="stylesheet" href="content.css">
10</head>
11
12<body>
13<div id="menu">
14 <div>
Stephan T. Lavavejf966d3f2017-08-31 17:59:4215 <a href="https://llvm.org/">LLVM Home</a>
Howard Hinnant56f0d5b2010-10-05 16:44:4016 </div>
17
18 <div class="submenu">
19 <label>libc++ Info</label>
20 <a href="/index.html">About</a>
21 </div>
22
23 <div class="submenu">
24 <label>Quick Links</label>
Stephan T. Lavavejf966d3f2017-08-31 17:59:4225 <a href="https://lists.llvm.org/mailman/listinfo/cfe-dev">cfe-dev</a>
26 <a href="https://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits</a>
Eric Fiselierb7fd0be2017-02-17 08:37:0327 <a href="https://bugs.llvm.org/">Bug Reports</a>
James Y Knighte0324cb2019-01-29 16:37:2728 <a href="https://github.com/llvm/llvm-project/tree/master/libcxx/">Browse Sources</a>
Howard Hinnant56f0d5b2010-10-05 16:44:4029 </div>
30</div>
31
32<div id="content">
33 <!--*********************************************************************-->
34 <h1>&lt;atomic&gt; design</h1>
35 <!--*********************************************************************-->
36
37<p>
Howard Hinnant086b7182010-10-06 16:15:1038There are currently 3 designs under consideration. They differ in where most
Howard Hinnant0dee9cd2013-02-15 15:37:5039of the implementation work is done. The functionality exposed to the customer
Howard Hinnant086b7182010-10-06 16:15:1040should be identical (and conforming) for all three designs.
Howard Hinnant56f0d5b2010-10-05 16:44:4041</p>
42
Howard Hinnant086b7182010-10-06 16:15:1043<ol type="A">
Howard Hinnant56f0d5b2010-10-05 16:44:4044<li>
Howard Hinnant086b7182010-10-06 16:15:1045<a href="atomic_design_a.html">Minimal work for the library</a>
Howard Hinnant56f0d5b2010-10-05 16:44:4046</li>
47<li>
Howard Hinnant086b7182010-10-06 16:15:1048<a href="atomic_design_b.html">Something in between</a>
Howard Hinnant56f0d5b2010-10-05 16:44:4049</li>
50<li>
Howard Hinnant086b7182010-10-06 16:15:1051<a href="atomic_design_c.html">Minimal work for the front end</a>
Howard Hinnant56f0d5b2010-10-05 16:44:4052</li>
Howard Hinnant086b7182010-10-06 16:15:1053</ol>
Howard Hinnant56f0d5b2010-10-05 16:44:4054
Howard Hinnant08f29692010-10-08 17:36:5055<p>
56With any design, the (back end) compiler writer should note:
57</p>
58
59<blockquote>
60<p>
61The decision to implement lock-free operations on any given type (or not) is an
62ABI-binding decision. One can not change from treating a type as not lock free,
63to lock free (or vice-versa) without breaking your ABI.
64</p>
65
66<p>
67Example:
68</p>
69
70<blockquote><pre>
71TU1.cc
72-----------
73extern atomic&lt;long long&gt; A;
74int foo() { return A.compare_exchange_strong(w, x); }
75
76TU2.cc
77-----------
78extern atomic&lt;long long&gt; A;
79void bar() { return A.compare_exchange_strong(y, z); }
80</pre></blockquote>
81</blockquote>
82
83<p>
84If only <em>one</em> of these calls to <tt>compare_exchange_strong</tt> is
85implemented with mutex-locked code, then that mutex-locked code will not be
86executed mutually exclusively of the one implemented in a lock-free manner.
87</p>
88
Howard Hinnant56f0d5b2010-10-05 16:44:4089</div>
90</body>
91</html>