commit 08f2969220ade83dbba368e186f8588ed4a2f6cd
author Howard Hinnant <hhinnant@apple.com> Fri Oct 08 17:36:50 2010 +0000
committer Howard Hinnant <hhinnant@apple.com> Fri Oct 08 17:36:50 2010 +0000
tree 76aad0ca78571052a851ba1bcd8b4bbbb87801d0
parent ffb9a4e235d0909859fdc4e1f98aa0fae5480ee4

Updated atomic design docs

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@116065 91177308-0d34-0410-b5e6-96231b3b80d8

www/atomic_design.html

diff --git a/www/atomic_design.html b/www/atomic_design.html
index 36e7324..87a2f62 100644
--- a/www/atomic_design.html
+++ b/www/atomic_design.html
@@ -53,6 +53,40 @@
 </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>