barrier

Recently, I am reading some Linux kernel space codes, I see this uint64_t used; uint64_t blocked; used = atomic64_read(&g_variable->used); //#1 barrier(); //#2 blocked = atomic64_read(&g_variable->blocked); //#3 What is the semantics of this code snippet? Does it make sure #1 executes before #3 by #2. But I am a litter bit confused, becasue #A In 64 bit platform, atomic64_read macro is expanded to used = (&g_variable->used)->counter // where counter is volatile. In 32 bits platform, it was converted to use lock cmpxchg8b . I assume these two have the same semantic, and for 64 bits version, I

I wrote some lock-free code that works fine with local reads, under most conditions. Does local spinning on a memory read necessarily imply I have to ALWAYS insert a memory barrier before the spinning read? (To validate this, I managed to produce a reader/writer combination which results in a reader never seeing the written value, under certain very specific conditions--dedicated CPU, process attached to CPU, optimizer turned all the way up, no other work done in the loop--so the arrows do point in that direction, but I'm not entirely sure about the cost of spinning through a memory barrier.)

I've been trying to get a project rid of every boost reference and switch to pure C++11. At one point, thread workers are created which wait for a barrier to give the 'go' command, do the work (spread through the N threads) and synchronize when all of them finish. The basic idea is that the main loop gives the go order (boost::barrier .wait()) and waits for the result with the same function. I had implemented in a different project a custom made Barrier based on the Boost version and everything worked perfectly. Implementation is as follows: Barrier.h: class Barrier { public: Barrier(unsigned