Home/ Questions/Q 7725147
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T04:52:01+00:00

I’m writing a game in which a thread – GameThread – loops forever, updating

  • 0

I’m writing a game in which a thread – GameThread – loops forever, updating all my sprites, rendering them, and then sleeping for some time before doing it all again. I also have a custom-made Event handler which deals with key presses etc.

This all works fine in most cases. However I have a problem if an event is thrown while GameThread is rendering. On rare occasions, the handler that deals with the event may make a concurrent change to what needs to be rendered affecting the results of the GameThread rendering.

To avoid this, I want the event handler to pause the GameThread immediately, handle the event, then resume GameThread.

  1. The suspend() / resume() methods suit my needs, but they were deprecated. In my case, however, as there is little chance of a deadlock, is it safe to use them regardless?

  2. If no, what other alternatives do I have that don’t have a huge amount of overhead?

I have seen a suggestion of requesting a thread to pause by setting a flag in the Thread to be paused. In my case, however, I don’t see that as a viable option since the GameThread loop may take a while during an iteration through the loop. I won’t be able to check the flag until I’m done with the loop and by then it is too late.

I need immediate pausing, or else the user will notice a delay in the event handling.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The suspend() / resume() methods suit my needs, but they were deprecated. In my case, however, as there is little chance of a deadlock, is it safe to use them regardless?

    Obviously, if there is ZERO chance of a deadlock then it is safe. But there are all sorts of unexpected ways to get a deadlock. For instance, you could happen to pause a thread while it is initializing a class … and that would deadlock any other thread trying to refer to a static field of that class. (This is a consequence of a specified behaviour of the JVM. There are other places where the locking / synchronization that goes on under the hood is not specified. Fair enough. It doesn’t need to be … unless you are contemplating using these deprecated methods.)

    So, the reality is that it is really difficult to determine (prove) if it is actually safe. And if you can’t determine this, then it is a potentially risky thing to do. That’s WHY the methods are deprecated.

    (Strictly speaking, this is not a deadlock. A deadlock is when the threads can never proceed. In this case, the other threads can proceed if you can resume the paused thread.)

    • 0