Home/ Questions/Q 7595501
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T21:41:14+00:00

I am developing an Android game and have a strange issue where occasionally the

  • 0

I am developing an Android game and have a strange issue where occasionally the game will become unresponsive for a long period of time before springing back into life. As far as I can tell, this pause, if it occurs at all, only happens when the game starts up. Once running normally the game seems to behave itself.

After some investigation, it appears that the onTouchEvent callback is becoming blocked trying to acquire a lock on the synchronization object it shares with the game thread. Meanwhile the game thread is running normally, and not holding onto a lock on the synchronization object for any long period of time.

It was my understanding that the synchronized block in doTouchEvent would acquire a lock on mSyncObject as soon as that lock had been released by the game thread. But in some cases, it appears that the game thread is able to acquire and release a lock several hundred times before doTouchEvent is eventually able to acquire its lock.

There is no other code that uses the same object for synchronization.

I’ve copied the relevant bits of code below. From what I can gather, it’s not doing anything out of the ordinary, so I am somewhat baffled by the strange behaviour that I am seeing.

Would appreciate any help on this one. Thanks in advance!

class GameThread extends Thread {

// ...some methods and members omitted...

private volatile int mFrameCount = 0; 
private Object mSyncObject = new Object();

@Override
public void run() {
    while (!mShutDown) {
        Canvas canvas = null;
        long timestampA = System.currentTimeMillis();
        try {
            synchronized (mSurfaceHolder) {
                canvas = mSurfaceHolder.lockCanvas(null);
                // Synchronized on our object...
                synchronized (mSyncObject) {
                    long now = System.currentTimeMillis();
                    if ((now > mLastTime) && !mPaused) {
                        double timestep = (double) (now - mLastTime) / 1000.0;
                        mGame.update(timestep);
                    }
                    mLastTime = now;
                    if (canvas != null) {
                        mGame.draw(canvas);
                    }
                }
            }
        } finally {
            if (canvas != null) {
                mSurfaceHolder.unlockCanvasAndPost(canvas);
            }
        }

        // have tried inserting a sleep() here, but it didn’t help

        ++mFrameCount;
    }
}


// Called from the UI thread
public boolean doTouchEvent(MotionEvent event) {
    boolean result = false;

    // Synchronized on our object... 
    // The game loop in run() acquires and releases a lock
    // on this object on every frame, so would expect to be
    // blocked here for no longer than one frame.
    // However, on occasions have been blocked here for over
    // 2000 iterations of the game loop. 
    int frameCount = mFrameCount;
    synchronized (mSyncObject) {
        int framesWaited = mFrameCount - frameCount;
        if (framesWaited > 1) {
            Log.i("Block", "doTouchEvent waited " + framesWaited + " frames for lock");
        }

        if (!(mPaused || mShutDown)) {
            result = mGame.doTouchEvent(event);
        }
    }
    return result;
}

}
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It would appear that this issue is down to the fact that synchronization offers no guarantee of fairness when it comes to the order in which waiting threads will acquire a lock. In fact, a thread can be kept waiting indefinitely for a lock if another cpu-intensive thread is repeatedly acquiring and releasing locks.

    See this thread discussing exactly the same issue…

    http://groups.google.com/group/android-developers/browse_frm/thread/ffe76e4a433c8675/f424fb7dc3baeb10

    …and here for an example of a thread-safe but synchronization-free solution.

    http://blog.tomgibara.com/post/208684592/avoiding-starvation

    Before stumbling upon the above, I changed my code to pass motion events between threads using a ConcurrentLinkedQueue, which also seemed effective in eliminating the stalls.

    • 0