CODEWITHSUNDEEP
javamultithreadingsynchronizationatomicmemory-model
Lingxi
Lingxi

Reputation: 14987

Atomicity and memory order in Java

I'm new to Java and is currently reading the book Java: A Beginner's Guide, 6th Edition. I come across some confusions with respect to atomicity and memory order in Java.

In the examples of the book that involving multithreading, concurrent access to shared resources (e.g., a shared variable) is not synchronized, nor are the shared resources specifically marked (e.g, atomic or volatile or something like that). For instance, in Try This 15-1 (page 519), concurrent access to the shared variable stopFlag is not serialized nor is the variable specifically marked either.

According to this, certain data types in Java are guaranteed to be atomic even if they are not specifically marked. This somewhat solves the consideration concerning atomicity. But how about memory order? Does the default treatment imply sequential-consistency like the default memory_order_seq_cst treatment on access to atomic types in C++?

Following are some critical code snippet from the example.

public class Banner extends Applet implements Runnable {
  String msg = " Java Rules the Web ";
  Thread t;
  boolean stopFlag;
  // Initialize t to null.
  public void init() {
    t = null;
  }

  // Start thread
  public void start() {
    t = new Thread(this);
    stopFlag = false;
    t.start();
  }

  // Entry point for the thread that runs the banner.
  public void run() {
    // Redisplay banner
    for( ; ; ) {
      try {
        repaint();
        Thread.sleep(250);
        if(stopFlag) break;
      } catch(InterruptedException exc) {}
    }
  }

  // Pause the banner.
  public void stop() {
    stopFlag = true;
    t = null;
  }

  // Display the banner.
  public void paint(Graphics g) {
    char ch;
    ch = msg.charAt(0);
    msg = msg.substring(1, msg.length());
    msg += ch;
    g.drawString(msg, 50, 30);
  }

Upvotes: 4

Views: 2134

Answers (2)

ZhongYu
ZhongYu

Reputation: 19682

No.

If you use data structures like AtomicInteger, then yes, set() operation implies a strong memory order, just like some other operations in the class. The word "Atomic" is used here to express that the class implement a set of atomic operations (e.g. compareAndSet) that ordinarily would be composed of sub-operations. Incidentally, these kind of data structures often follow strong memory orders, and by word association, "atomic", used in this kind of context, often implies strong memory order. (But not always true though, e.g. lazySet and weakCompareAndSet in AtomicInteger)

Back to your question, the word "atomic" there has no such connotation, it simply means the write is indivisible. But that is meaningless. What is meaningful is to say that a write to a non-volatile long or double variable is "non-atomic" because it is equivalent to two writes (JLS#17.7). Other writes are not-non-atomic.

Upvotes: 4

Misha
Misha

Reputation: 28163

As the answer you linked explains, atomicity and visibility are completely different concepts. Atomicity of ints insures that if a thread changes an int value from 5 to -7, other threads may observe either 5 or -7 but never anything else.

Visibility deals with when the other threads are guaranteed to see that the variable changed from 5 to -7.

The example in your book is probably meant to illustrate that unless stopFlag variable is declared as volatile, its modification from one thread may become visible to other threads right away or some indeterminate time later or even never.

Upvotes: 3

Related Questions