Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #2713 > unrolled thread

About serquential consistency

Back to article view | Back to comp.programming.threads

Contents

  About serquential consistency Ramine <ramine@1.1> - 2014-11-24 16:09 -0800
    Re: About serquential consistency anastasiossouris@gmail.com - 2014-11-29 02:33 -0800

#2713 — About serquential consistency

Hello,


I think i have understood correctly RMO  (Relaxed Memory Ordering) of
Sparc RMO and ARM and i have understood correctly TSO (Total Store 
Ordering) of x86.. but i have a question please...


If you have noticed on my previous post about a Seqlock that
was wrote in Java, you will notice that it is using sfences
and lfences to avoid problems with sequential consistency on
RMO (Relaxed Memory Ordering) and TSO  (Total Store Ordering),
but i feel sincerely that RMO (Relaxed Memory Ordering) is
really dangerous, cause for example what will happen to this
Seqlock if the call to Spinlock.lock() inside this Seqlock didn't 
contain an MFENCE !? this will become a serious bug and this will become 
dangerous and fatal.. so this is why i am kind of afraid of RMO (Relaxed 
Memory Ordering) cause RMO higher the complexity and this can introduce 
easily serious and fatal bugs...

So my question is: Why have we choose RMO even though that it is
dangerous ?


Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#2723

On Monday, November 24, 2014 11:08:58 PM UTC+2, Ramine wrote:
> Hello,
> 
> 
> I think i have understood correctly RMO  (Relaxed Memory Ordering) of
> Sparc RMO and ARM and i have understood correctly TSO (Total Store 
> Ordering) of x86.. but i have a question please...
> 
> 
> If you have noticed on my previous post about a Seqlock that
> was wrote in Java, you will notice that it is using sfences
> and lfences to avoid problems with sequential consistency on
> RMO (Relaxed Memory Ordering) and TSO  (Total Store Ordering),
> but i feel sincerely that RMO (Relaxed Memory Ordering) is
> really dangerous, cause for example what will happen to this
> Seqlock if the call to Spinlock.lock() inside this Seqlock didn't 
> contain an MFENCE !? this will become a serious bug and this will become 
> dangerous and fatal.. so this is why i am kind of afraid of RMO (Relaxed 
> Memory Ordering) cause RMO higher the complexity and this can introduce 
> easily serious and fatal bugs...
> 
> So my question is: Why have we choose RMO even though that it is
> dangerous ?
> 
> 
> Thank you,
> Amine Moulay Ramdane.

That's an issue for hardware folks... Relaxed memory ordering performs better because the cores in a manycore machine can avoid doing extra work...

Think that if an architecture implemented a sequential consistent memory model you would only need to perform atomic loads and stores and no memory barriers at all. So it is easier for you the programmer. BUT, the architecture underneath will implement in hardware those memory fences for you in EVERY load and store you perform.

Next one realizes that ordering memory actions between different processors is not essential for every load and store. But only when you need it... 

So the hardware guys say to you: 
Well get those cheap load and stores you want. And if you want to order memory actions then i give to you those extra memory barriers instructions (which are costly with respect to other instructions), and you have to place them where they are needed. 
So, the hardware runs fast in the common case and CAN also run fast in the case where synchronization is needed if you succeed in placing only the required memory fences and no more.
This certainly adds to the complexity a programmer has to face when implementing a lock-free algorithm and that's why you don't like it! :)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web