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

Groups > comp.programming.threads > #2712

About Seqlock and sequantial consistency

Show all headers | View raw

Hello again,


This time i am in the process of porting a Java program
of a Seqlock that i have understood completly to Delphi and FreePascal...

But i have to validate my reasoning about the sequential consistency
of this Seqlock..

Here is the Seqlock:


---

public final class SeqLock {

     private long counter;
     private volatile int mfence;

     private final ILock spin;

     public SeqLock() {
         this.counter = 0;
         this.spin = new AtomicBackoffLock();
         // must perform at least one volatile write to conform to JMM
         this.mfence = 0;
     }

     @SuppressWarnings("unused")
     public long readBegin() {
         long ret = counter;
         long lfence = mfence;   // lfence
         return ret;
     }

     @SuppressWarnings("unused")
     public boolean readRetry(long v) {
         long lfence = mfence;   // lfence
         return (v & 1) == 1 || counter != v; // v is odd or sequence 
number is changed
     }

     public void writeLock() {
         spin.lock();
         ++counter;
         mfence = 0; // sfence
     }

     public void writeUnlock() {
         mfence = 0; // sfence
         counter++;
         spin.unlock();
     }

     /**
      * assumes only one writer
      */
     public void writeBegin() {
         ++counter;
         mfence = 0; // sfence
     }

     /**
      * assumes only one writer
      */
     public void writeEnd() {
         mfence = 0; // sfence
         counter++;
     }

}

---


So notice with me that on RMO (Relaxed Memory Ordering) like on ARM etc. 
this algorithm of a Seqlock needs the sfences and a lfences , and notice 
that on RMO the spin.lock() and  spin.unlock() must contain an mfence to 
avoid problems, but on TSO (Total Store Ordering) in x86 architecture i 
think this algorithm don't need sfence on the write side , cause in the 
writeLock() the loads can not go above the spinlock.lock() and the 
stores of counter in writeUnlock() can not go above cause in the TSO the 
stores are not reordered with older stores or older loads...

I think on TSO that's the same for readBegin(), they don't need
lfence on TSO cause the stores and loads can not be reordered with the 
older load of counter inside readBegin(), and on TSO the loads of 
counter inside readRetry() can be reordered with older stores, so we 
need to maintain the lfence in readRetry().


Can you tell me if my reasoning is correct ?



Thank you,
Amine Moulay Ramdane.

Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread

Thread

About Seqlock and sequantial consistency Ramine <ramine@1.1> - 2014-11-24 15:15 -0800

csiph-web