Welcome to the Java Programming Forums


The professional, friendly Java community. 21,500 members and growing!


The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.


>> REGISTER NOW TO START POSTING


Members have full access to the forums. Advertisements are removed for registered users.

Results 1 to 7 of 7

Thread: synchronization

  1. #1
    Member
    Join Date
    Jul 2010
    Posts
    45
    Thanks
    10
    Thanked 3 Times in 3 Posts

    Default 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?
    Last edited by helloworld922; August 28th, 2010 at 10:33 AM.


  2. #2
    Member
    Join Date
    Jul 2010
    Posts
    45
    Thanks
    10
    Thanked 3 Times in 3 Posts

    Default Re: synchronization

    Oops, apparently the answer is yes, it does release the lock. But what is the point of synchronizing anything? According to the author, a boolean cannot be read by one thread and changed by another at the same time because the JMM prevents it.

    No other thread will ever be executing the code in run() besides the animator thread. So why synchronize it?

    And what is the harm in multiple threads calling resumeGame()?

  3. #3
    Super Moderator helloworld922's Avatar
    Join Date
    Jun 2009
    Posts
    2,895
    Thanks
    23
    Thanked 619 Times in 561 Posts
    Blog Entries
    18

    Default Re: synchronization

    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).

  4. #4
    Member
    Join Date
    Jul 2010
    Posts
    45
    Thanks
    10
    Thanked 3 Times in 3 Posts

    Default Re: synchronization

    I have a basic understanding of a mutex, but not a lot of hands on experience with threads in general. Basically, my understanding is that all code in synchronized blocks is known as the monitor, and any thread which wants to execute this monitor code must first acquire a mutex (lock) on the object. If the mutex has already been acquired by another thread, the requesting thread must wait until it releases the lock before it can execute the monitor code.

    Are the following statements correct? This is how I am thinking and I want to see if I am on the right track.

    The thread scheduler is responsible for managing the CPU time of the threads, and it does this based on the thread's priority. So if thread A is running, the thread scheduler could decide that it has had enough CPU time, and let thread B run for a while.

  5. #5
    Member
    Join Date
    Jul 2010
    Posts
    45
    Thanks
    10
    Thanked 3 Times in 3 Posts

    Default Re: synchronization

    I think my problem is that I understand synchronization, but I'm not understanding how it works here.

    1. pauseGame() is called and isPaused is set to true.

    2. the animator thread will check this at the beginning of the next iteration

    3. the animator thread finds that isPaused is true, so it acquires the lock for the object

    4. the animator thread then goes into a wait state (which releases the lock) <- what is the point of acquiring the lock when it will be immediately released when wait() is invoked? is this to be sure the thread executing resumeGame() completes before the animation thread wakes up?

    5. when the game is to be resumed, resumeGame() is called by a thread which acquires the lock for that object <- the lock is acquired here because one thread may be in the middle of notifying the animation thread, and it has to finish before another thread starts executing code to do the same thing

    I actually get more confused the more that I think about it.

  6. #6
    Super Moderator helloworld922's Avatar
    Join Date
    Jun 2009
    Posts
    2,895
    Thanks
    23
    Thanked 619 Times in 561 Posts
    Blog Entries
    18

    Default Re: synchronization

    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.

  7. The Following User Says Thank You to helloworld922 For This Useful Post:

    bbr201 (August 29th, 2010)

  8. #7
    Member
    Join Date
    Jul 2010
    Posts
    45
    Thanks
    10
    Thanked 3 Times in 3 Posts

    Default Re: synchronization

    Ahh, I think I see what you are saying. If it wasn't set up this way, it's actually possible that the separate thread could set isPaused to false AND execute notify() before the animator thread enters its wait state. If this happens, the animator thread could be waiting forever (unless resumeGame() is called again).

    This makes sense if I think about it this way.

    Wow, it really is difficult to consider all of the possibilities...

Similar Threads

  1. Database synchronization from RMS with MySQL in Online mode
    By jeremyraj in forum Java ME (Mobile Edition)
    Replies: 1
    Last Post: January 24th, 2011, 08:08 AM