Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>First, some petty remarks:</h2> <pre><code>volatile T obj; </code></pre> <p>volatile is useless here, even more that you make all the barriers yourself.</p> <pre><code>inline T operator++( int ) </code></pre> <p>inline is unneeded, since it is implied when the method is defined inside the class.</p> <h2>Getters and setters:</h2> <pre><code>inline operator T() { __sync_synchronize(); // (I) T tmp=obj; __sync_synchronize(); // (II) return tmp; } inline atomic&lt; T &gt; &amp; operator=( T val ) { __sync_synchronize(); // (III) obj = val; __sync_synchronize(); // (IV) return *this; } </code></pre> <p>To assure total ordering of the memory accesses on read and write, you need two barriers on each access (like this). I would be happy with only barriers (II) and (III) as they suffice for some uses I came up with (eg. pointer/boolean saying data is there, spinlock), but, unless specified otherwise, I would not omit the others, because someone might need them (it would be nice if someone showed you can omit some of the barriers without restricting possible uses, but I don't think it's possible).</p> <p>Of course, this would be unnecessarily complicated and slow.</p> <p>That said, I would just dump the barriers, and even the idea of using the barriers in any place of a similar template. Note that:</p> <ul> <li>the ordering semantics of that interface is all defined by you; and if you decide the interface has the barriers here or there, they must be here or there, period. If you don't define it, you can come up with more efficient design, because not all barriers, or even not full barriers, might be needed for a particular problem.</li> <li>usually, you use atomics if you have a lock-free algorithm that could give you a performance advantage; this means an interface that prematurely pessimizes the accesses will probably be unusable as a building block of it, as it will hamper the performance itself.</li> <li>lock-free algorithms typically contain communication that cannot be encapsulated by one atomic data type, so you need to know what's happening in the algorithm to place the barriers precisely where they belong (eg. when implementing a lock, you need a barrier <em>after</em> you've acquired it, but <em>before</em> you release it, which are both writes, at least in principle)</li> <li>if you don't wanna have problems, and are not sure about placing the barriers explicitly in the algorithm, just use lock-based algorithms. There's nothing bad about it.</li> </ul> <p>BTW, the c++0x interface allows you to specify precise memory ordering constraints.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload