<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <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>