1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 2<html> 3<head> 4<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 5<title>Limitations</title> 6<link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css"> 7<meta name="generator" content="DocBook XSL Stylesheets V1.79.1"> 8<link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset"> 9<link rel="up" href="../atomic.html" title="Chapter 6. Boost.Atomic"> 10<link rel="prev" href="usage_examples.html" title="Usage examples"> 11<link rel="next" href="porting.html" title="Porting"> 12</head> 13<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> 14<table cellpadding="2" width="100%"><tr> 15<td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td> 16<td align="center"><a href="../../../index.html">Home</a></td> 17<td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td> 18<td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> 19<td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> 20<td align="center"><a href="../../../more/index.htm">More</a></td> 21</tr></table> 22<hr> 23<div class="spirit-nav"> 24<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> 25</div> 26<div class="section"> 27<div class="titlepage"><div><div><h2 class="title" style="clear: both"> 28<a name="atomic.limitations"></a><a class="link" href="limitations.html" title="Limitations">Limitations</a> 29</h2></div></div></div> 30<p> 31 While <span class="bold"><strong>Boost.Atomic</strong></span> strives to implement the 32 atomic operations from C++11 and later as faithfully as possible, there are 33 a few limitations that cannot be lifted without compiler support: 34 </p> 35<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> 36<li class="listitem"> 37 <span class="bold"><strong>Aggregate initialization syntax is not supported</strong></span>: 38 Since <span class="bold"><strong>Boost.Atomic</strong></span> sometimes uses storage 39 type that is different from the value type, the <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><></span></code> template needs an initialization 40 constructor that performs the necessary conversion. This makes <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><></span></code> 41 a non-aggregate type and prohibits aggregate initialization syntax (<code class="computeroutput"><span class="identifier">atomic</span><span class="special"><</span><span class="keyword">int</span><span class="special">></span> <span class="identifier">a</span> <span class="special">=</span> <span class="special">{</span><span class="number">10</span><span class="special">}</span></code>). 42 <span class="bold"><strong>Boost.Atomic</strong></span> does support direct and unified 43 initialization syntax though. <span class="bold"><strong>Advice</strong></span>: 44 Always use direct initialization (<code class="computeroutput"><span class="identifier">atomic</span><span class="special"><</span><span class="keyword">int</span><span class="special">></span> <span class="identifier">a</span><span class="special">(</span><span class="number">10</span><span class="special">)</span></code>) 45 or unified initialization (<code class="computeroutput"><span class="identifier">atomic</span><span class="special"><</span><span class="keyword">int</span><span class="special">></span> <span class="identifier">a</span><span class="special">{</span><span class="number">10</span><span class="special">}</span></code>) 46 syntax. 47 </li> 48<li class="listitem"> 49 <span class="bold"><strong>Initializing constructor is not <code class="computeroutput"><span class="keyword">constexpr</span></code> 50 for some types</strong></span>: For value types other than integral types and 51 <code class="computeroutput"><span class="keyword">bool</span></code>, <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><></span></code> initializing constructor needs 52 to perform runtime conversion to the storage type. This limitation may 53 be lifted for more categories of types in the future. 54 </li> 55<li class="listitem"> 56 <span class="bold"><strong>Default constructor is not trivial in C++03</strong></span>: 57 Because the initializing constructor has to be defined in <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><></span></code>, 58 the default constructor must also be defined. In C++03 the constructor 59 cannot be defined as defaulted and therefore it is not trivial. In C++11 60 the constructor is defaulted (and trivial, if the default constructor of 61 the value type is). In any case, the default constructor of <code class="computeroutput"><span class="identifier">atomic</span><span class="special"><></span></code> 62 performs default initialization of the atomic value, as required in C++11. 63 <span class="bold"><strong>Advice</strong></span>: In C++03, do not use <span class="bold"><strong>Boost.Atomic</strong></span> in contexts where trivial default constructor 64 is important (e.g. as a global variable which is required to be statically 65 initialized). 66 </li> 67<li class="listitem"> 68 <span class="bold"><strong>C++03 compilers may transform computation dependency 69 to control dependency</strong></span>: Crucially, <code class="computeroutput"><span class="identifier">memory_order_consume</span></code> 70 only affects computationally-dependent operations, but in general there 71 is nothing preventing a compiler from transforming a computation dependency 72 into a control dependency. A fully compliant C++11 compiler would be forbidden 73 from such a transformation, but in practice most if not all compilers have 74 chosen to promote <code class="computeroutput"><span class="identifier">memory_order_consume</span></code> 75 to <code class="computeroutput"><span class="identifier">memory_order_acquire</span></code> 76 instead (see <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448" target="_top">this</a> 77 gcc bug for example). In the current implementation <span class="bold"><strong>Boost.Atomic</strong></span> 78 follows that trend, but this may change in the future. <span class="bold"><strong>Advice</strong></span>: 79 In general, avoid <code class="computeroutput"><span class="identifier">memory_order_consume</span></code> 80 and use <code class="computeroutput"><span class="identifier">memory_order_acquire</span></code> 81 instead. Use <code class="computeroutput"><span class="identifier">memory_order_consume</span></code> 82 only in conjunction with pointer values, and only if you can ensure that 83 the compiler cannot speculate and transform these into control dependencies. 84 </li> 85<li class="listitem"> 86 <span class="bold"><strong>Fence operations may enforce "too strong" 87 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 88 reordering of memory operations only in one direction. Since in C++03 there 89 is no way to express this constraint to the compiler, these act as "full 90 compiler barriers" in C++03 implementation. In corner cases this may 91 result in a slightly less efficient code than a C++11 compiler could generate. 92 <span class="bold"><strong>Boost.Atomic</strong></span> will use compiler intrinsics, 93 if possible, to express the proper ordering constraints. 94 </li> 95<li class="listitem"> 96 <span class="bold"><strong>Atomic operations may enforce "too strong" 97 memory ordering in debug mode</strong></span>: On some compilers, disabling 98 optimizations makes it impossible to provide memory ordering constraints 99 as compile-time constants to the compiler intrinsics. This causes the compiler 100 to silently ignore the provided constraints and choose the "strongest" 101 memory order (<code class="computeroutput"><span class="identifier">memory_order_seq_cst</span></code>) 102 to generate code. Not only this reduces performance, this may hide bugs 103 in the user's code (e.g. if the user used a wrong memory order constraint, 104 which caused a data race). <span class="bold"><strong>Advice</strong></span>: Always 105 test your code with optimizations enabled. 106 </li> 107<li class="listitem"> 108 <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> 109 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>. 110 Same with <code class="computeroutput"><span class="identifier">atomic_ref</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code>. 111 </li> 112<li class="listitem"> 113 <span class="bold"><strong>Signed integers must use <a href="https://en.wikipedia.org/wiki/Two%27s_complement" target="_top">two's 114 complement</a> representation</strong></span>: <span class="bold"><strong>Boost.Atomic</strong></span> 115 makes this requirement in order to implement conversions between signed 116 and unsigned integers internally. C++11 requires all atomic arithmetic 117 operations on integers to be well defined according to two's complement 118 arithmetics, which means that <span class="bold"><strong>Boost.Atomic</strong></span> 119 has to operate on unsigned integers internally to avoid undefined behavior 120 that results from signed integer overflows. Platforms with other signed 121 integer representations are not supported. Note that C++20 makes two's 122 complement representation of signed integers mandatory. 123 </li> 124<li class="listitem"> 125 <span class="bold"><strong>Types with padding bits are not supported</strong></span>: 126 As discussed in <a class="link" href="interface.html#atomic.interface.interface_atomic_ref.caveats" title="Caveats">this 127 section</a>, <span class="bold"><strong>Boost.Atomic</strong></span> cannot support 128 types with padding bits because their content is undefined, and there is 129 no portable way to initialize them to a predefined value. This makes operations 130 like <code class="computeroutput"><span class="identifier">compare_exchange_strong</span></code>/<code class="computeroutput"><span class="identifier">compare_exchange_weak</span></code> fail, and given 131 that in some cases other operations are built upon these, potentially all 132 operations become unreliable. <span class="bold"><strong>Boost.Atomic</strong></span> 133 does support padding bits for floating point types on platforms where the 134 location of the padding bits is known at compile time. 135 </li> 136</ul></div> 137</div> 138<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> 139<td align="left"></td> 140<td align="right"><div class="copyright-footer">Copyright © 2011 Helge Bahmann<br>Copyright © 2012 Tim Blechmann<br>Copyright © 2013, 2017, 2018, 2020 Andrey 141 Semashev<p> 142 Distributed under the Boost Software License, Version 1.0. (See accompanying 143 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>) 144 </p> 145</div></td> 146</tr></table> 147<hr> 148<div class="spirit-nav"> 149<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> 150</div> 151</body> 152</html> 153
