thread safe code : Java Glossary

Here are your tools for writing thread-safe code.

• Single Thread Code

  This is the technique most programmers use. However, if the code later has to be multithread, it is much harder to retrofit than to build that in at the start.

• Confining Code To Thread

  This is what Swing does. It confines all code that manipulate the Swing objects to the EDT (Event Dispatch Thread) thread. Then it does not need to worry about tripping over itself, though bugs creep in when people inadvertently touch Swing objects from some other thread.

• Immutable Objects

  Threads can look at objects without interference so long as the fields never change value. 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.

• Local variables

  Every Thread has its own private 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 (Java Virtual Machine) does not cache volatile values in registers. On every use, it fetches the value from main shared RAM (Random Access Memory). 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 (Central Processing Unit) billions of events happen every second, so that highly improbable things happen frequently, or, even more infuriatingly, only during demos. volatile is a weaker but faster mechanism than locking. The main time you would use it is to set a flag to request some code abort gracefully. volatile guarantees that 64-bit fetch or store (long) will work atomically, even on a 32-bit architecture that does the operation is two parts.

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

• 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  Java version 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

The easiest way to start a Thread is to implement Runnable on some class. All you have to do is say implements Runnable and write a run method that is called when the Thread forks (starts). However, you don’t call run directly.

// 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:

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 (Graphic User Interface) 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 unpredictably 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

You would get an erroneous result balance + depositAmount1 rather than balance + depositAmount1 + depositAmount2.

If instead you wrote:

Then only one thread at a time could access the account record containing the balance field and the code would have to run like this:

More Than Just Atomicity

To have multi-thread code work, you need more than just atomic method calls.

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 technique for instance variables in objects with many threads competing for access.

Books

Book referral for Java Concurrency in Practice

	recommend book⇒Java Concurrency in Practice
	by	Brian Goetz, Tim Peierls, Joshua J. Bloch, Joseph Bowbeer, David Holmes, Doug Lea	978-0-321-34960-6	paperback
	publisher	Addison-Wesley	978-0-13-270225-6	eBook
	published	2006-05-19	B004V9OA84	kindle
Bloch and Lea especially have very good reputations in concurrent programming. This is the dream team to write such a book.
Online bookstores carrying Java Concurrency in Practice abe books anz abe books.ca abe books.de amazon.ca amazon.de Chapters Indigo amazon.es Chapters Indigo eBooks iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Nook at Barnes & Noble amazon.it Kobo junglee.com Google play abe books.co.uk O’Reilly Safari amazon.co.uk Powells other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Book referral for Concurrent Programming in Java(TM): Design Principles and Patterns, third edition

	recommend book⇒Concurrent Programming in Java(TM): Design Principles and Patterns, third edition
	by	Douglas Lea	978-0-321-25617-1	paperback
	publisher	Addison-Wesley
	published	2006-05-19
Threads and concurrency in Java, design considerations (safety, liveness and performance), Before/After Patterns, layering, adapters, immutability and synchronization, deadlock, resource ordering, the Java Memory Model and concurrency, using the java.concurrency package, confinement, refactoring for concurrency, mutexes, read-write locks, recovering from failure, notifications, semaphores, latches, exchanges, transactions, one-way messages, worker threads, polling and event-driven I/O, parallelism techniques (fork/join, computation trees and barriers), Communicating Sequential Processes (CSP).
Online bookstores carrying Concurrent Programming in Java(TM): Design Principles and Patterns, third edition abe books anz abe books.ca abe books.de amazon.ca amazon.de Chapters Indigo amazon.es Chapters Indigo eBooks iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Nook at Barnes & Noble amazon.it Kobo junglee.com Google play abe books.co.uk O’Reilly Safari amazon.co.uk Powells other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Learning More