[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming.threads

About Seqlock and sequantial consistency

Ramine

11/24/2014 11:15:00 PM


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.