| <!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><atomic> 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="http://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="http://lists.llvm.org/mailman/listinfo/cfe-dev">cfe-dev</a> | |
| <a href="http://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits</a> | |
| <a href="http://llvm.org/bugs/">Bug Reports</a> | |
| <a href="http://llvm.org/svn/llvm-project/libcxx/trunk/">Browse SVN</a> | |
| <a href="http://llvm.org/viewvc/llvm-project/libcxx/trunk/">Browse ViewVC</a> | |
| </div> | |
| </div> | |
| <div id="content"> | |
| <!--*********************************************************************--> | |
| <h1><atomic> 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<long long> A; | |
| int foo() { return A.compare_exchange_strong(w, x); } | |
| TU2.cc | |
| ----------- | |
| extern atomic<long long> 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> |