5 ms·

> A safer bet would be to use __atomic_load and __atomic_store Safer and an order of magnitude slower.

• exDM69 10y ago
  Sure, but the only way to be sure that a non-atomic store works as intended is to read the assembly output from the compiler. It's also not very easy to predict the relative difference because it depends on which core(s) the threads get scheduled on. If both threads happen to get on the same core and the data stays in caches, we're talking about 1ns (L1) to 5ns (L2). An atomic load/store would be about 20ns (4..20x slower). If they happen to get scheduled on different cores, the CPU interconnect will have to deal with its cache coherency protocol (similar to atomic load/store) and the result will be around the same. We're talking about pretty miniscule amount of time here. It's a choice between fast if you're lucky but possibly incorrect anyway or marginally slower but guaranteed correctness.
  • Unklejoe 10y ago
    Wouldn't this be the case anyway (cache coherency overhead) even if we used types that just-so-happened to be atomic on the platform, such as "int"? In other words, isn't this a non issue when comparing the performance of atomic types and "regular" types, as they both would require this? Also, do the atomic types handle ordering? I could be going crazy, but I remember seeing some of those atomic types simply being typedef'd to "int" in some OS code before. EDIT: I was thinking of the "atomic_t, atomic_inc, atomic_set, etc..." in the Linux Kernel. It guarantees atomic behavior, but not ordering. Memory barriers are still required when using it between different threads. The C11 types appear to be different, as they accept an ordering argument in their load/store functions.
    • anarazel 10y ago
      Many of them actually do provide guarantees (as e.g. evidenced that a typical implementation of an x86 memory barrier is an "lock; addl $0,0(%%rsp)"). That's why there's now stuff like __smp_mb__before_atomic()/__smp_mb__after_atomic(), to avoid unnecessary atomic ops.
  • jblow 10y ago
    No. The way to ensure that your store works atomically is to specify the assembly output of the compiler. Reading what it is outputting right now doesn't matter, because how do you know when it is going to change its mind?
    • exDM69 10y ago
      You don't know. That's why it's a terrible solution. No-one inspects their binaries after every recompilation or compiler (flag) change.
• anarazel 10y ago
  Why would a relaxed load/store be slower? They'll usually just compile down to a mov or whatever the equivalent is?