-2
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicInteger;

public class Main implements Runnable {

   private final CountDownLatch cdl1 = new CountDownLatch(NUM_THREADS);
   private volatile int bar = 0;
   private AtomicInteger count = new AtomicInteger(0);

   private static final int NUM_THREADS = 25;

   public static void main(String[] args) {
      Main main = new Main();
      for(int i = 0; i < NUM_THREADS; i++)
         new Thread(main).start();
   }

   public void run() {
      int i = count.incrementAndGet();
      cdl1.countDown();
      try {
         cdl1.await();
      } catch (InterruptedException e1) {
         e1.printStackTrace();
      }
      bar = i;
      if(bar != i)
         System.out.println("Bar not equal to i");
      else
         System.out.println("Bar equal to i");
   }

}

Each Thread enters the run method and acquires a unique, thread confined, int variable i by getting a value from the AtomicInteger called count. Each Thread then awaits the CountDownLatch called cdl1 (when the last Thread reaches the latch, all Threads are released). When the latch is released each thread attempts to assign their confined i value to the shared, volatile, int called bar.

I would expect every Thread except one to print out "Bar not equal to i", but every Thread prints "Bar equal to i". Eh, wtf does volatile actually do if not this?

It is a deliberate intention that each Thread attempts to set the value of bar at exactly the same time.

EDIT:

In light of the answer, changed code to this:

...
bar = i;
try {
    Thread.sleep(0);
} catch(InterruptedException e) {
    e.printStackTrace();
}
...

To ensure that a little time is wasted between the set and read of the variable.

Now the print is 50/50 on same/different value for Bar.

Finbarr
  • 31,350
  • 13
  • 63
  • 94
  • 5
    @Finbarr: **WHAT ABOUT USING LANGUAGE LIKE 'wtf does volatile actually do' and acting like a prick on his high horse when people are actually trying to help you**? It's not the first time I see you answering like a prick here to people trying to help you. – SyntaxT3rr0r May 08 '10 at 00:02
  • @Finbarr: and volatile is not useless. See here for a question about volatile with 11 upvotes and 4 favorites asked by someone much smarter than you in a "non-wtf way": http://stackoverflow.com/questions/2441279/java-volatile-guarantees-and-out-of-order-execution – SyntaxT3rr0r May 08 '10 at 00:04
  • In response to your edit... "To ensure that a little time is wated between the set and read of the variable" Unfortunately, you have no control about when any thread may actually do what you want it to do. Stop trying to force control without using a locking mechanism. – wheaties May 08 '10 at 00:05
  • 2
    "Volatile" does not mean "software transactional memory". If you want STM, use STM. – jrockway May 08 '10 at 00:06
  • The problem with textual communication is the ambiguity of tone. – Finbarr May 08 '10 at 00:25
  • Also, I only have 11 questions and there doesn't seem to be anything controversial in any of them...? – Finbarr May 08 '10 at 00:35

5 Answers5

8

The JVM decides when the threads run, not you. If it felt like holding one of the ones whose latch just released for another 10ms, just because, it can do that. After the latch releases, they still have to wait for their turn to execute. Unless you're running it on a 25 core computer, they're not all assigning bar at anywhere near 'the same time' down inside the machine. Since all you're doing is a couple of primitive operations, it's extremely unlikely that one of them won't finish inside its time slice before the next one gets released!

Affe
  • 47,174
  • 11
  • 83
  • 83
  • Interesting fact is however, when I replace that `if-else` block by `System.out.println("Bar equal to i? " + (bar == i));`, then I start to see the odds. – BalusC May 08 '10 at 00:02
  • Makes sense, especially if there's something that the JVM blocks on for a bit while giving the native console printer to a thread, another waiting thread would get a time slice. – Affe May 08 '10 at 00:05
2

It's not. You're misusing it. There is a great article here by Herb Sutter that explains it in more detail.

The basic idea is that volatile makes variables unoptimisable. It does not make them thread safe.

Chris Bednarski
  • 3,364
  • 25
  • 33
2

To answer the 'WTF does volatile actually do?':

volatile is all about visibility. In Java's thread model, if a thread A writes into a regular shared field, there is no guarantee that a thread B will ever see the value written by A, unless the threads are synchronized somehow. volatile is one of the synchronization mechanisms.

Unlike non-volatile fields, when thread A writes into a volatile field and thread B later reads it, B is guaranteed to see the new value and not an older version.

(Actually volatile does even more - thread B will not only see the new value of the field, but everything else written by A before it set the volatile variable as well. It established a happened-before relationship).

Tim Jansen
  • 3,330
  • 2
  • 23
  • 28
1

What you should do is replace your instance of volatile int with AtomicInteger. See here.

wheaties
  • 35,646
  • 15
  • 94
  • 131
0

I think you meant to write this:

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicInteger;

public class Main implements Runnable {

   private final CountDownLatch cdl1 = new CountDownLatch(NUM_THREADS);
   private volatile int bar = 0;
   private AtomicInteger count = new AtomicInteger(0);

   private static final int NUM_THREADS = 25;

   public static void main(String[] args) {
      Main main = new Main();
      for(int i = 0; i < NUM_THREADS; i++)
         new Thread(main).start();
   }

   public void run() {
      int i = count.incrementAndGet();
      bar = i;
      cdl1.countDown();
      try {
         cdl1.await();
      } catch (InterruptedException e1) {
         e1.printStackTrace();
      }
      if(bar != i)
         System.out.println("Bar not equal to i");
      else
         System.out.println("Bar equal to i");
   }

}

Which prints "Bar not equal to i" like you expected.

SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
  • 1
    What would be the point of that? Of course that will print out "Bar not equal to i" as every thread is setting the value at several nanosecond intervals. I wrote the code in such a way that every thread would try to set the value of bar at exactly the same time deliberately. – Finbarr May 07 '10 at 23:51