Home > Programming > Series About Java Concurrency – Pt. 3

Series About Java Concurrency – Pt. 3

As it seems that even experienced Java programmers might have serious misconceptions regarding the Java memory model, I’ve decided to publish a concurrency related puzzle once again. Consider the following simple program and try to predict it’s output:

package com.wordpress.mlangc.concurrent;

public class PleaseWait
{
    private static final long MILLIS_TO_WAIT = 2500;
    private static boolean stop = false;
    
    public static void main(String[] args)
    {
        Thread timer = new Thread(new Runnable()
        {
            public void run()
            {
                try
                {
                    Thread.sleep(MILLIS_TO_WAIT);
                }
                catch(InterruptedException e)
                {
                    // We are already exiting the thread.
                }
                finally
                {
                    stop = true;
                    System.out.println("Stop requested.");
                }
            }
        });
        
        timer.start();
        
        long start = System.currentTimeMillis();
        while(!stop)
            ; // <-- Do nothing.
        
        long stoppedAfter = System.currentTimeMillis() - start;
        System.out.printf("Stopped after %dms.\n", stoppedAfter);
    }
}

The solution, together with explanations will be published in the near future.

Advertisements
Categories: Programming Tags: , ,
  1. JLA
    May 12, 2011 at 04:05

    I don’t get it. Doesn’t making the stop variable volatile solve the problem?

    • May 13, 2011 at 14:35

      Yes, by making the variable volatile we can make sure that the main thread sees the update done by the timer thread in line 24. In it’s current form however, the program might as well loop forever, which is exactly what it does with sun-jdk-1.6.24 when run in server mode.

  2. Orion Edwards
    May 20, 2011 at 05:08

    I ran this on .NET 4.0 – it’s a bit different but still exhibits the same bug:

    If you make the stop flag a static member variable in .NET, it always seems to stop regardless of whether or not you make it volatile.

    however if you make the methods non-static, and make the stop flag an *instance* variable, then it stops in Debug builds, but release builds only get the “stop requested” and that’s it.

    FYI, making it a local variable and using a closure has the same result as an instance variables, as .NET implements closures by simply hoisting “closed-over” variables into instance variables on an auto-generated class.

  3. Will C.
    May 21, 2011 at 00:18

    I take it you have experienced a ‘lost update issue’ somewhere too? (I can’t find your concurrency pt.2! )

    Nice blog though, keep it up 🙂

    • May 22, 2011 at 13:01

      Yes, I have in fact experienced a ‘lost update issue’ in real code quite recently. While I was able to fix it quickly, I discovered that this might not have been true for some of my colleagues, which motivated this blog post.

    • May 22, 2011 at 13:04

      You can find pt. 2 here.

  4. December 29, 2012 at 14:34

    good article.. thanks for sharing.. 🙂

  1. May 19, 2011 at 22:59

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: