It doesn’t seem to be possible in a single operation, but you can make a loop, that tries to do this, until it finally succeeds or value in atomic variable becomes bigger than value: template<typename T> void update_maximum(std::atomic<T>& maximum_value, T const& value) noexcept { T prev_value = maximum_value; while(prev_value < value && !maximum_value.compare_exchange_weak(prev_value, value)) {} … Read more
Bottom line (TL;DR): LFENCE alone indeed seems useless for memory ordering, however it does not make SFENCE a substitute for MFENCE. The “arithmetic” logic in the question is not applicable. Here is an excerpt from Intel’s Software Developers Manual, volume 3, section 8.2.2 (the edition 325384-052US of September 2014), the same that I used in … Read more
“Natural” alignment means aligned to its own type width. Thus, the load/store will never be split across any kind of boundary wider than itself (e.g. page, cache-line, or an even narrower chunk size used for data transfers between different caches). CPUs often do things like cache-access, or cache-line transfers between cores, in power-of-2 sized chunks, … Read more
I think this a great question and John Calsbeek has the correct answer. However, just to be clear a lazy singleton is best implemented using the classic Meyers singleton. It has garanteed correct semantics in C++11. ยง 6.7.4 … If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall … Read more
b = !b is not atomic because in the C++ source you have an atomic pure read of b (equivalent to b.load(), and then a separately-atomic assignment to b (equivalent to b.store()). Nothing makes the entire combination into an atomic RMW operation in the C++ abstract machine, and there’s no syntax for composing arbitrary operations … Read more
The C++11 memory ordering parameters for atomic operations specify constraints on the ordering. If you do a store with std::memory_order_release, and a load from another thread reads the value with std::memory_order_acquire then subsequent read operations from the second thread will see any values stored to any memory location by the first thread that were prior … Read more
Your usage does not actually ensure the things you mention in your comments. That is, your usage of fences does not ensure that your assignments to a are visible to other threads or that the value you read from a is ‘up to date.’ This is because, although you seem to have the basic idea … Read more
The write is atomic but an increment also requires a read. So the question is: Are you sure the read is safe, in other words, are you sure another thread doing the increment will not end up with the same value to be incremented? I have doubts. The 100% correct way of doing this would … Read more
The note gives a clue, referring to LL/SC architectures. From the Wikipedia article: If any updates have occurred, the store-conditional is guaranteed to fail, even if the value read by the load-link has since been restored. As such, an LL/SC pair is stronger than a read followed by a compare-and-swap (CAS), which will not detect … Read more
The final solution is combining the symlink- and the rename-approach: mkdir alpha_real ln -s alpha_real alpha # now use “alpha” mkdir beta_real ln -s beta_real tmp # atomically rename “tmp” to “alpha” # use -T to actually replace “alpha” instead of moving *into* “alpha” mv -T tmp alpha Of course, the application accessing alpha has … Read more