Thread: synchronization

hi all,

i haven't worked with threads much, and i have a question about how synchronzied would work in this situation. here is a stripped down example of a game class:

public class GamePanel extends JPanel implements Runnable
{
	private Thread			animator;
	public volatile boolean	running		= true;
	public volatile boolean	isPaused	= false;
 
	public GamePanel()
	{
		animator = new Thread(this);
		animator.start();
	}
 
	@Override
	public void run()
	{
		while (running)
		{
			if (isPaused)
			{
				synchronized (this)
				{
					while (isPaused && running)
					{
						wait(); // try/catch omitted to keep it simple for
								// example
					}
				}
			}
		}
	}
 
	public void pauseGame()
	{
		isPaused = true;
	}
 
	public synchronized resumeGame()
	{
		isPaused = false;
		notify();
	}
}

Basically, I assume the user presses P and the event-dispatch thread calls the appropriate event handler which calls pauseGame(). The animator thread is always running while the game isn't paused to update/render the game.

So, let's say the user pauses the game and isPaused is called. Then, in the next iteration of the animator thread's while loop, it will enter the synchronized block and enter a wait state.

Does the object become unlocked when a thread enters the wait state? If not, how will another thread call resumeGame() since the object is already locked by the animation thread?

even though isPaused is atomic, notify() isn't, and the combination of assigning to the boolean and notify() definately isn't atomic.

Are you familiar with the notion of a mutex? Synchronization provides a mechanism for acquiring a mutex lock for the specified object so that you can guarantee that only one thread is operating on that object. This isn't always necessary, particularly when the only command that is happening is atomic (for example, look how pauseGame isn't synchronized).

Is there any more code provided? It is likely that there should be some updating code that is executed on the animator thread but the author chose not to include at this point.

Accessing one boolean is atomic, accessing two is not (which could be why the author chose to put this inside of a synchronized loop).

I believe that after the wait() call, the animator thread re-gains the lock for that object so it is guaranteed that it will have full control of isPaused and running at the same time.

It is possible that without this guarantee that this could happen:

1. Animator accesses isPaused and evaluates to true
2. A separate thread changes the value of isPaused to false
3. Animator accesses running and evaluates to true

So whatever code that requires to program to not be paused and running will indeed run when the program is paused. A very slim chance, but it's there non the less and can potentially cause extremely difficult problems to debug.