Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <pre><code>inline operator T() { __sync_synchronize(); // Not sure this is overkill return obj; } </code></pre> <p>Short version: This IS overkill. </p> <p>Long version:</p> <p>Why do you want to implement this class as a template at all? It doesn't make sense because the atomic operations are allowed only on integer types from 1-8 bytes and you even can't be sure that an 8 byte integer is supported on all platforms.</p> <p>You should implement your atomic class as a non-template version and use the "native" integer type of your hardware/system. This is int32_t on 32 bit processors/os and int64_t on a 64 bit systems. e.g.:</p> <pre><code>#ifdef ... typedef ... native_int_type; #endif // verify that you choosed the correct integer type BOOST_STATIC_ASSERT(sizeof(native_int_type) == sizeof(void*)); </code></pre> <p>BOOST_STATIC_ASSERT is straight forward to "static_assert()" from C++0x.</p> <p>If you're using the "perfect fit" integer type you can write the operator just like that:</p> <pre><code>operator native_int_type() { return obj; } </code></pre> <p>Because obj is volatile it's guaranteed to fetch the value and not return any cached value. And because you're using the "native" integer type you can be sure that reading such a value is atomic.</p> <pre><code>atomic&amp; operator=( native_integer_type val ) </code></pre> <p>Again, you don't need a synchronize if you're using the right integer type. Read/Set an int32 on a intel 32 bit system is atomic and so is Read/Set an int64 on a 64 bit system.</p> <p>I don't see any benefit from implementing atomic as a template. Atomic operations are platform dependent. It's better to offer an "atomic_int" class that just guarantees to has at least 4 byte (if you're supporting 32bit and 64bit systems) and an "atomic_pointer" if you need it. This way the name of the class also implies a semantic and a purpose.</p> <p>If you just use "atomic" than one could think: "Wow, i just have to put my string class in this template and then it's thread safe!".</p> <hr> <p>Edit: to Answer your update: "I want to make sure that the operations are consistent in the face of read/write re-ordering due to compiler optimisations."</p> <p>To prevent compiler and cpu to reorder read/write operations you need the __sync_synchronize().</p> <p>But note that acquire/release semantics may yield better performance than full barriers.</p> <hr> <p>Edit2:</p> <pre><code>inline atomic&lt; T &gt; &amp; operator=( T val ) { __sync_synchronize(); // Not sure if this is overkill obj = val; return *this; } </code></pre> <p>What do you want prevent from reordering? In most cases you want to write this:</p> <pre><code> obj = val; __sync_synchronize(); </code></pre> <p>instead. Because you want to be sure that the value is written, once you returned from the function.</p>
    singulars
    1. This table or related slice is empty.
    1. POC++0x atomic implementation in c++98 question about __sync_synchronize()
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USneverlord
    1. USneverlord
    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. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    1. COJust because an operation is atomic doesn't mean memory barriers are unnecessary. Without them, the read/write might be cached and delayed for an unspecified amount of time. Or it might get reordered, changing the semantics of your code.
      singulars
      1. PO
      1. USjalf
    2. CO@neverlord. I agree with your appraisal of implementing the atomic ops as templates and the only reason I did was because, as I understand, the c++0x defines it's atomics as "atomic< int >" etc. I agree that someone looking at the code may well think that "atomic< string >" is valid. However, I was going to make sure that an type handed in for "T" would be integer type and be within the range allowed for the host. I just hadn't got that far yet :o)
      singulars
      1. PO
      1. USScaryAardvark
    3. CO@jalf. This is what I was driving at. I want to make sure that the value is consistent in the face of optimisations. Are you saying that this extra "__synchronize()" is necessary ?
      singulars
      1. PO
      1. USScaryAardvark
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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