| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> |
| <title>Limitations</title> |
| <link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css"> |
| <meta name="generator" content="DocBook XSL Stylesheets V1.78.1"> |
| <link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset"> |
| <link rel="up" href="../atomic.html" title="Chapter 5. Boost.Atomic"> |
| <link rel="prev" href="usage_examples.html" title="Usage examples"> |
| <link rel="next" href="porting.html" title="Porting"> |
| </head> |
| <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
| <table cellpadding="2" width="100%"><tr> |
| <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td> |
| <td align="center"><a href="../../../index.html">Home</a></td> |
| <td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td> |
| <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> |
| <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> |
| <td align="center"><a href="../../../more/index.htm">More</a></td> |
| </tr></table> |
| <hr> |
| <div class="spirit-nav"> |
| <a accesskey="p" href="usage_examples.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../atomic.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="porting.html"><img src="../../../doc/src/images/next.png" alt="Next"></a> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h2 class="title" style="clear: both"> |
| <a name="atomic.limitations"></a><a class="link" href="limitations.html" title="Limitations">Limitations</a> |
| </h2></div></div></div> |
| <p> |
| While <span class="bold"><strong>Boost.Atomic</strong></span> strives to implement the |
| atomic operations from C++11 as faithfully as possible, there are a few limitations |
| that cannot be lifted without compiler support: |
| </p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> |
| <li class="listitem"> |
| <span class="bold"><strong>Using non-POD-classes as template parameter to <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> |
| results in undefined behavior</strong></span>: This means that any class containing |
| a constructor, destructor, virtual methods or access control specifications |
| is not a valid argument in C++98. C++11 relaxes this slightly by allowing |
| "trivial" classes containing only empty constructors. <span class="bold"><strong>Advise</strong></span>: Use only POD types. |
| </li> |
| <li class="listitem"> |
| <span class="bold"><strong>C++98 compilers may transform computation- to control-dependency</strong></span>: |
| Crucially, <code class="computeroutput"><span class="identifier">memory_order_consume</span></code> |
| only affects computationally-dependent operations, but in general there |
| is nothing preventing a compiler from transforming a computation dependency |
| into a control dependency. A C++11 compiler would be forbidden from such |
| a transformation. <span class="bold"><strong>Advise</strong></span>: Use <code class="computeroutput"><span class="identifier">memory_order_consume</span></code> only in conjunction |
| with pointer values, as the compiler cannot speculate and transform these |
| into control dependencies. |
| </li> |
| <li class="listitem"> |
| <span class="bold"><strong>Fence operations enforce "too strong" compiler |
| ordering</strong></span>: Semantically, <code class="computeroutput"><span class="identifier">memory_order_acquire</span></code>/<code class="computeroutput"><span class="identifier">memory_order_consume</span></code> and <code class="computeroutput"><span class="identifier">memory_order_release</span></code> need to restrain |
| reordering of memory operations only in one direction. Since there is no |
| way to express this constraint to the compiler, these act as "full |
| compiler barriers" in this implementation. In corner cases this may |
| result in a less efficient code than a C++11 compiler could generate. |
| </li> |
| <li class="listitem"> |
| <span class="bold"><strong>No interprocess fallback</strong></span>: using <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> |
| in shared memory only works correctly, if <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><</span><span class="identifier">T</span><span class="special">>::</span><span class="identifier">is_lock_free</span><span class="special">()</span> <span class="special">==</span> <span class="keyword">true</span></code>. |
| </li> |
| </ul></div> |
| </div> |
| <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> |
| <td align="left"></td> |
| <td align="right"><div class="copyright-footer">Copyright © 2011 Helge Bahmann<br>Copyright © 2012 Tim Blechmann<br>Copyright © 2013 Andrey Semashev<p> |
| Distributed under the Boost Software License, Version 1.0. (See accompanying |
| file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>) |
| </p> |
| </div></td> |
| </tr></table> |
| <hr> |
| <div class="spirit-nav"> |
| <a accesskey="p" href="usage_examples.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../atomic.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="porting.html"><img src="../../../doc/src/images/next.png" alt="Next"></a> |
| </div> |
| </body> |
| </html> |
