On Tuesday, April 3, 2018 at 5:44:38 AM UTC-7, Dmitry Vyukov wrote:
>
> On Sat, Mar 31, 2018 at 10:41 PM, Chris M. Thomasson 
> <cri...@charter.net <javascript:>> wrote: 
> > Notice how there is an acquire barrier inside of the CAS loop within the 
> > enqueue and dequeue functions of: 
> > 
> > 
> > 
> http://www.1024cores.net/home/lock-free-algorithms/queues/bounded-mpmc-queue 
> > 
> > 
> > ? 
> > 
> > 
> > Well, fwiw we can get rid of them by using stand alone fences: 
> > 
> > 
> > Btw, sorry for the membar abstraction. I can quickly get sick and tired 
> of 
> > having to type out (std::memory_order_relaxed) all the damn time. ;^) 
> > 
> > 
> > Anyway, here is the simple code using Relacy: 
> > 
> > ___________________ 
> [...]
> > ___________________ 
> > 
> > 
> > 
> > There is no need for any membars within the loops. The version count 
> keeps 
> > everything in order. 
>
> compare_exchange in C/C++ has optional failure memory ordering, so the 
> following looks equivalent to me ;) 
>
> m_tail.compare_exchange_weak(ver, ver + 1, acquire, relaxed) 
>

Yes, you are correct about that. However, I personally like to keep 
everything relaxed, and only add memory barriers when they are absolutely 
needed. The stand alone fence can do this. Ahh, perhaps I am thinking too 
much of SPARC with its awesome membar instruction. For instance, the 
acquire barrier you have in the CAS loop in your MPMC queue code is what a 
stand alone fence can get rid of. Think of the following line of code, that 
is within the loop:

 size_t seq =

        cell->sequence_.load(std::memory_order_acquire);


Executing an acquire barrier on every iteration of the CAS loop is not 
necessary. The actual version count keeps everything in order. 


However, you do need a single acquire fence _after_ the CAS loop succeeds in 
order to get a clear view of the element.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/c86d0f23-84a1-4e17-91ac-a37db3bb5184%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to