Too many cooks spoil the broth. When several threads operate on the same data - the data can be corrupted, the value of data maybe unpredictable.
For example, in the SimpleGame example, x and y coordinates are shared by two threads. The periodic mover-thread changed these values and also the same values are changed by a user touching the keyboard.

If, by chance, both threads try to access these coordinates at the same time, the results are not well predictable.

This situation is called race condition, when two pieces of code compete for access to data. By the way, the winner is the last one who overwrites any change done by the first thread.

To prevent these troubles, Java introduced the synchronized keyword and a related mechanism that allows a synchronized thread to finish its work before any other thread can start.
This means that threads can access serialized or locked code/data once at a time, which makes data safe. Developers call it thread-safe code.

Thread-safety is a concern, which comes up when an application closely interact with an operating system.
Networking, drawing a heavy-weight screen on a display, database access, using common variables on a server side by multiple users, for example a counter of visitors.

In such cases we might choose thread-safe Java classes. For example, Hashtable or ConcurrentHashMap are more safe than light-weight HashMap, while they keep same functionality.

You also need to think of thread-safe behavior/methods.
For example, the method remove() in any implementation of the List interface will not be thread-safe, especially in the loop. Even synchronize version of the method will not help.

But in the most cases making threads to work sequentially, not in parallel, is a safety option.

It is obvious that synchronization slows down performance of a program. To minimize the impact, select for synchronization the smallest piece of code where critical race conditions occur.

In the SimpleGame this critical piece of code was in the keyTyped() method. Both threads called this method to change data.

We cannot change the method signature by adding the synchronized keyword, because this method is defined not by us, but by the KeyListener interface.
But we can move selected code to another method, which we make synchronized.
This is our current code that we need to make thread-safe.


/**

 * As a KeyListener this class MUST implement three methods below.

 * The program uses only one of them, keyTyped(), to handle key events

 * Not all keys are handled, but some change the calculations of coordinates, color, and size of a target.

 * On each key event, generated by a thread or initiated by a user, this method repaint the target.

 * @param key event

 */

    public void keyTyped(KeyEvent e) {

        char command = e.getKeyChar();

        if(command == '0') {

        	x = 0;

        	y = 0;

        } else if(command == '>') {

        	weight +=5;

        } else if(command == '<') {

        	weight -=5;

        } else if(command == 'u') {

        	y -= 10;

        	color = Color.yellow;

        } else if(command == 'd') {

        	y += 10;

        	color = Color.DARK_GRAY;

        } else if(command == 'l') {

        	x -= 10;

        	color = Color.LIGHT_GRAY;

        } else if(command == 'r') {

        	x += 10;

        	color = Color.red;

        } else if(command == 'b') {

        	color = Color.blue;

        } else {

	        x += 10;

	        y += 10;

        }

        if(x == 540 && y == 40 && weight == 40 && color == Color.red) {

        	endOfGame = true;

        }

        repaint();	

    }





We modify our code above to the following.



	public void keyTyped(KeyEvent e) {

        // the command variable is internal for the method, 

        // it is not shared and thread-safe

        char command = e.getKeyChar();

        // we move our code that changes shared data to a new method

        handleKey(command);

        // repaint does not change the data and 

        // for the paint process multithreading is extremely important

        repaint();

	}

	/**

	 * thread-safe key handler

	 * @param command

	 */

	public synchronized void handleKey(char command) {

        if(command == '0') {

        	x = 0;

        	y = 0;

        } else if(command == '>') {

        	weight +=5;

        } else if(command == '<') {

        	weight -=5;

        } else if(command == 'u') {

        	y -= 10;

        	color = Color.yellow;

        } else if(command == 'd') {

        	y += 10;

        	color = Color.DARK_GRAY;

        } else if(command == 'l') {

        	x -= 10;

        	color = Color.LIGHT_GRAY;

        } else if(command == 'r') {

        	x += 10;

        	color = Color.red;

        } else if(command == 'b') {

        	color = Color.blue;

        } else {

	        x += 10;

	        y += 10;

        }

        if(x == 540 && y == 40 && weight == 40) {

        	endOfGame = true;

        }			

    }

Was it clear so far?

Assignments:

1. Modify and run again the SimpleGame class
2. You might not notice any changes as the race condition that might happen in the previous version is a very rare although possible occasion.