Runnable posted by handler sees wrong object state (race condition?)

Question

I'm running into a very strange issue here with wrong object state that I see in methods posted as Runnables using Handler.postDelayed. I use this to schedule draw calls for 2D drawing, and this draw code checks certain state fields (like ints and booleans).

Now it can happen that these state fields change after I schedule a draw, but since all methods, even the delayed calls are executed on the same thread (right?), there should be no visibility issues due to shared state.

Still, I sometimes see a flag being e.g. false in a scheduled draw, even though it can't possibly be, since I set it to true before scheduling the draw and don't touch it again. Some pseudo sample code:

public void scheduleDraw() {
    boolean flag = true;
    handler.postDelayed(runnable);
}

runnable = new Runnable() {
    public void run() {
        // flag is false here
    }
}

How can this happen? I'm not entirely sure how Android implements these message loops, but I checked for thread identity in both the methods that schedule the draw and the scheduled method itself, and they're both invoked on the same thread (the main UI thread).

This is driving me crazy, can someone help?

UPDATE I noticed that the problem is due to the flag being checked once by an inner class, and once by an outer class. The draw code runs as part of the inner class and sees the flag in its correct state, whereas the outer class, even though it contains a reference to an instance of the inner class, always sees the flag as false (the incorrect state). I still don't understand the problem, but it seems it's related to the class nesting?

Answer 1

I found the issue: the outer class was keeping a reference to the inner class, of which several instances could be active at once (and switched). Since they shared the handler of the outer class, the outer class would sometimes receive delayed messages on the handler callback from the one that just turned inactive.

I don't share any variables anymore now between the outer and inner class.

Thanks a lot for your help though! Appreciated.

Answer 2

There are a couple issues I can see here.

First, in your example code you declare flag as a locally scoped variable within scheduleDraw(). I can't even see how runnable could access it.

Assuming that is just a typo and that flag is a class variable... simply setting a boolean to true does not mean that all threads will see the same value instantly. In Java some variable writes can be cached thread-locally, meaning other threads WILL actually see an inconsistent value. One way to avoid this is to declare a variable volatile. For example:

private volatile boolean flag;

Doing this tells the Java runtime that this variable should never be cached thread-locally and all reads and writes should go straight to "main memory".

Another solution is to use an instance of an AtomicBoolean from the java.util.concurrent.atomic package

private AtomicBoolean flag = new AtomicBoolean();
...
flag.set(true);