1

Ok so I just read this question Do you ever use the volatile keyword in Java?, and I get using a volatile variable in order to stop a loop. Also I've seen this reference, http://www.javamex.com/tutorials/synchronization_volatile.shtml. Now the article says that volatile variables are non-blocking. Also it says that it cannot be used for concurrency in a read-update-write sequence. Which makes sense because they're non-blocking.

Since volatile variables are never cached is it faster to simply use synchronization to stop the loop (from the earlier link)?

Edit: Using a synchronized solution 

public class A{
  private boolean test;

  public A(){
    test = true;
  }

  public synchronized void stop(){
    test = false;
  }

  public synchronized boolean isTrue(){
    return test;
  }
}

public class B extends Thread {
  private A a;

  public B(A refA){
    a = refA;
  }

  public void run(){
    //Does stuff here
    try{
      sleep(1000);
    }
    catch(Exception e){}
    a.stop();
  }

  public static void main(String [] args){
    A TestA = new A();
    B TestB = new B(TestA);
    TestB.start();
    while(TestA.isTrue()){
      //stay in loop
      System.out.println("still in loop");
    }
    System.out.println("Done with loop");
  }
 }
Community
  • 1
  • 1
Albinoswordfish
  • 1,949
  • 7
  • 34
  • 50
  • 1
    What loop are you talking about? Please include an example of your proposed usage of `synchronized` in the question. – erickson Aug 19 '10 at 18:10
  • Goto the first link I posted and look for the highest rated answer. – Albinoswordfish Aug 19 '10 at 18:24
  • 1
    your expecting a lot of your readers. Next time, just include the example in the question ... – Stephen C Aug 19 '10 at 18:34
  • I did look at that answer, but it describes the correct use of `volatile`. I wanted you to provide an example of how you'd use `synchronized` instead, so that I could give more specific advice. – erickson Aug 19 '10 at 19:09

2 Answers2

5

No, reading a volatile variable is faster than than reading an non-volatile variable in a synchronized block.

A synchronized block clears the cached values on entry which is the same as reading a volatile variable. But, it also flushes any cached writes to main memory when the synchronized block is exited, which isn't necessary when reading volatile variable.

erickson
  • 265,237
  • 58
  • 395
  • 493
  • Caches are not flushed and main memory doesn't need to be involved at all. In case of an unlock and volatile write, the CPU stops issuing loads till the store buffer has been drained. If the cache line of the write isn't in MODIFIED or EXCLUSIVE state, a Request for Ownership is done to invalidate the cache line in other caches and once that is granted, the write can complete to the L1D cache. Cache lines can live in caches indefinitely. Apart from capacity reasons, there is no reason to write a cache line to main memory... ever... – pveentjer May 19 '20 at 12:31
2

There's a numebr of things wrong in your question: You can do a reliable read-update-write with volatile so long as you use Atomic*FieldUpdater and a cas-loop. Volatiles can be "cached", they just need to obey the relevant happens-before semantics specified.

Synchronisation typically involves obtaining a lock, which is relatively expensive (although may actually be quite cheap). Simple concurrent optimisations may use non-naive implementation techniques.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305