thread safe code : Java Glossary

Here are your tools for writing thread-safe code.

• Local variables

  Every Thread has its own set of local variables stored in a stack frame. There is no possible way a Thread can interfere with another Thread’s local variables. You will often see Sun code where at the beginning of a method it fetches everything into local variables, then computes, then stores everything back into instance and class variables. The advantage of this approach is local variables cannot spontaneously change by the actions of other Threads. A method that does nothing but examine or modify local variables or primitive parameters is automatically thread safe. As soon as it goes modifying fields in objects it did not create, there is potential for trouble.

• The volatile keyword

  It warns the compiler that other Threads may change an instance or class variable at any time, and that the compiler should not cache that value in a register, least it be stale. Volatile does not imply any locking. It simply that the compiler/JVM does not cache volatile values in registers. On every use, it fetches the value from main shared RAM. On every assignment it saves the value to main shared RAM. In a multicpu machine with cache coherency, the value may not actually be stored all the way back to RAM, but logically it is. Declaring a long or double volatile also ensures it is fetched and stored atomically in one indivisible 64 bit chunk, rather than two 32 bit chunks one after the other as is normal. Volatile is insufficient to ensure even code as simple as x++ works. Pathologically you could see this happening: Thread (a) reads x, thread (a) increments x in a register, thread (b) reads x, thread (b) increments x in a register, thread (b) saves x, thread (a) saves x. The result is only one increment instead of two. You may think this highly improbable, but in the nanoscopic world of the CPU billions of events happen every second, so that highly "improbable" things happen frequently, or, even more infuriatingly, only during demos.

• The synchronized keyword

  Think of synchronized as temporarily locking an object to have exclusing access to it for modifications or study. synchronized marks a block of code or an entire method as critical. Only one Thread can be in it at once executing. Other Threads automatically sleep waiting their turn to use it. For a synchronized instance method, the synchronized code can be run by other Thread on other objects simultaneously, since the locking is on the object. For a synchronized class method, the locking in on the class object, which thus limits to only one Thread executing that code.

  Does the synchronized mechanism lock Threads out of the object in all critical regions or the object in just one critical region? It is the first. All critical sections locked with the same object are blocked. Keep in mind that you can use an object other than the one you are working on as the locking object. This would let you for example allow two groups of critical code to be executing simultaneously, provided they locked on different objects, e.g. a dummy inner class locking object. Understand that the objects themselves are not locked. Other threads can access them with non-sychronised methods, even when they are locked. It also means you could have critical code acting on thousands of different objects funnelled to single processing stream by locking all the critical code on a single lock object. This would not be efficient, but would be theoretically possible.

• wait, notify and sleep

  For inter-Thread communication you can use Thread.wait and Thread.notify. Thread.wait goes to sleep until some other Thread wakes it up. Thread.notify wakes up some other Thread. Thread.sleep goes to sleep for some specified number of milliseconds, unless some other Thread wakes it up first.

• Immutable Objects

  Immutable objects, (ones without any setter methods, e.g. Integer) are automatically thread safe. They are read-only. Combine that with final references, and you don’t need to worry all about what other threads are doing. Instead of modifying fields in an object, and risking it being in an indeterminate state, you create a new object, and then replace the object as a whole with the new one is one atomic operation, setting a new reference.

• interrupt

  One Thread can interrupt another with Thread.interrupt. The most common use is to wake up a sleeping Thread prematurely, or to abort a long i/o. If a Thread is computing, interrupting it will have no effect until it does a sleep or wait etc. Interrupting a Thread will cause it to immediately wake the next time it tries to sleep. A Thread can even interrupt itself.

  Unfortunately you can’t use interrupt to abort just any i/o. It can really only be used for that when using the JDK 1.4 java.nio I/O. In particular when using a Channel that implements InterruptibleChannel, which includes channels for files, pipes and networking. Thread.interrupt is not guaranteed to wake up any thread blocked in any other I/O operation.

See the warning under Gotchas:Threads on why a sleeping task may never waken if somebody fiddles with the system clock setting while your thread is asleep.

start versus run

// running on the same thread
aRunnable.run();

If you do, run will be called like a normal method, with no new Thread created. You must create a Thread object and then call start on the Thread object instead.

// starting a Thread
Thread thread = new Thread( aRunnable );
thread.start();
// which will then execute arunnable.run() on a separate Thread.

SwingUtilities.invokeLater

You are not on the Swing event thread when main first starts up! You are on it in your event listeners. You are tell if you are on it with:

// Either method will work in
    Java 1.3+
// to determine if you are running on the
dispatch thread,
// the same for AWT or Swing.

// in Swing
boolean onSwingThread 
= javax.
swing.SwingUtilities.
isEventDispatchThread();

// in AWT
boolean onDispatchThread 
= java.
awt.EventQueue.
isDispatchThread();

// Dump info about the current thread, name,
priority, group.
System.
out.println
( Thread.
currentThread() 
);

// Dump name of the current thread
System.
out.println
( Thread.
currentThread().
getName() 
);

One of the most common errors is to tie up the AWT/Swing event thread with some long running computation or even a sleep. Everything freezes up. The GUI can’t respond to mouse clicks and no repainting happens. You have to spin the time-consuming task off on its own thread or use a Timer.

If you violate these rules, the entire system starts to behave unpredicably and irrationally. If by violating these rules, you manage to create two event-processing threads, life gets really interesting as they unpredictably fight with each other handling Swing events.

Why You Need Synchronized Methods

If instead you wrote:

More Than Just Atomicity

For example, imagine a banking system with a getBalance() method to examine the balance, and another withdraw( long withdrawAmount) method to update the a balance.

However, between the method call to look at the balance and update the balance, another withdrawal transaction could come in and snaffle the funds. The withdrawal would improperly go ahead, leaving a correctly-computed overdraft.

For such code to work in a thread-safe way, the withdrawal method must do an atomic integral last-minute check on the balance, as well as an atomic increment on the balance such as the sample code for a withdrawal in the example on why synchronized is needed.

Static

One trick you can use for static variable contention is to introduce static references to dummy lock objects new Object(). Instead of locking the whole class, you lock just one of the lock objects which represents access to some subset of the member variables. You can also use the techique for instance variables in objects with many threads competing for access.

Books

	recommend book⇒Java Concurrency in Practice
		paperback	kindle
	ISBN13:	978-0-321-34960-6	B000RH0EPC
	ISBN10:	0-321-34960-1
	publisher:	Addison-Wesley
	published:	2006-05-19
	by:	Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea
Bloch and Lea especially have very good reputations in concurrent programming. This is the dream team to write such a book. See the companion website with code examples, a sample chapter, errata etc..
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com abe books anz

	recommend book⇒Concurrent Programming in Java: Design Principles and Patterns, Second Edition
		paperback
	ISBN13:	978-0-201-31009-2
	ISBN10:	0-201-31009-0
	publisher:	Prentice Hall
	published:	1999-01-04
	by:	Doug Lea
432 pages. You can read it online. This is the book on Threads and concurrent programming. The only problem with it is does not cover the new java.util.concurrent package which the author helped design.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com abe books anz