Thread : Java Glossary

*0-9ABCDEFGHIJKLMNOPQRSTUVWXYZ (all)

threads  Thread

Even trivial Java apps are designed to run on multi-CPU machines with execution streams running in parallel. Each stream is called a thread. Each thread, by default, gets one megabyte of virtual RAM (Random Access Memory) reserved for its stack just in case it wants to grow. So 2000 threads would require 2 gig of virtual RAM, — which all by itself would fill the largest possible 32-bit virtual RAM space in a Wintel machine. You can configure this the stack space per thread on the java.exe command line with the -Xss 640000 option to configure a 640K stack.

Native vs Green Threads Current Thread
Daemon Threads Synchronized
Thread Safety Rendezvous
Swing Threads Volatile
Timers Thread Gotchas
Thread Tools java.util.concurrent
Starting a Thread Debugging
Sleeping Books
Setting Priority Learning More
Death Watch/Stopping Links

Native vs Green Threads

Threads may be implemented by the JVM (Java Virtual Machine) as native OS (Operating System) threads or alternatively as green threads. Microsoft’s term for green threads is fibers. Multiple green threads are simulated threads using one native thread. Green threads can’t take advantage of multiple CPU (Central Processing Unit) s, but they have the advantage of lighter weight for context switching and RAM usage.

Natural Bridge used a hybrid of green and native which allows scalability to thousands of threads. An early Solaris Java had green threads. Pretty well the rest of thread implementations are native. You, as application programmer, have no way, in pure Java, to control which kind of threads are used.

Daemon Threads

Threads that work in the background to support the runtime environment are called daemon threads. For example, the clock handler thread, the idle thread, the screen updater thread, and the garbage collector thread are all daemon threads. The virtual machine exits whenever all non-daemon threads have completed. The daemon threads are then all automatically stopped when the JVM shuts down.

Thread Safety

Some collections such as Vector and Hashtable are thread-safe, where ArrayList and HashMap are not. You can safely work with thread-safe collections simultaneously from two different threads, adding and looking up elements. You cannot with the others. The AWT (Advanced Windowing Toolkit) is thread-safe; Swing is not. Thread safe code is usually slower, so you don’t make code thread safe unless necessary. All Swing code should be run on the event thread, either directly or via SwingUtilities. invokeLater or EventQueue. invokeLater. However, Sun is reneging on the AWT-is-thread-safe claim and are now recommending you put all AWT GUI (Graphic User Interface) code on the Swing thread too. Of course you can’t do that if you want your code to run in

The good news is, even though you are using Runnable, you don’t have the overhead of actually creating a new Thread since you are just calling the run method on the already existing Swing Thread.

You are not on the Swing event thread when main first starts up! You are on it

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.

There are two fundamental things to understand about Swing and threads:

  1. Time-consuming tasks should not be run on the EDT (Event Dispatch Thread) aka Swing thread. Otherwise the application becomes unresponsive. The EDT is busy executing your task and hence can’t process GUI events.
  2. Swing components should be accessed on the EDT only. To access components from other threads, you must use SwingUtilities. invokeAndWait, SwingUtilities. invokeLater or SwingWorker.

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.

In general, multi-thread code is tricky, however, if you can arrange that threads don’t modify the same variables or look at variables other threads are modifying, just look at the same final variables, there is nothing to Threads. You don’t need any synchronization. Local variables are private to each thread so they are not a problem either.

Timers

If you want a task to be run at some time in the future or repeatedly at regular intervals, you can schedule it with the java.util.Timer class. This is more efficient than spawning separate sleeping threads yourself. Timer uses one Thread to track the entire schedule.

Thread Tools

Where practical, use existing thread-safe objects, like AtomicLong, to manage your class’s state. It is simpler to reason about the possible states and state transitions for existing thread-safe objects that it is for arbitrary state variables, and his makes it easier to maintain and verify thread safety.
~ Brian Goetz Java Concurrency in Practice page 23
With the following basic tools you can craft all manner of complex interactions.

Starting up a new Thread

All you need is a class, perhaps the current one that has a run method and that has implements Runnable on the class declaration. Here is a simple example of such a class:

The run method gets executed on a separate thread. When run returns, the thread dies, and cannot be revived or restarted. Don’t call a Runnable’s run method directly. If you do, you will not start a new Thread; you will just run the method in the ordinary way on the current thread. You must use start which creates a new thread and then calls run for you. To start the new thread you need some code like this:

// execute InParallel.run()
// in parallel to this thread on a new thread.
Thread t = new Thread ( new InParallel() );

// Note we call t.start(), not t.run()
// t.run() would just call run in the ordinary way.
t.start();

Don’t forget to set your thread variable (t in the example above) to null when you no longer need it. You don’t have to wait till the thread terminates. If you don’t, you will end up with a useless dead Thread object cluttering your heap.

There is another technique where you extend the Thread class and override its run method, but it is not as flexible.

ThreadLocal is a technique of providing per-thread variables that without having to build them into the Thread object. Roughly speaking it makes a static variable into an automatically managed array, one slot per each active thread.

was not originally part of JDK (Java Development Kit). You had to it separately. It lets you convert some long-running event handling code into a separate thread with just a line of extra code.

Sleeping

You can put the current Thread to sleep for a period of time. It will awake prematurely if some other thread does a thread.interrupt() to it. It that case it will wake with an exception rather than naturally.

try
   {
   // put current thread to sleep
   Thread.sleep( delayInMilliseconds );
   }
catch ( InterruptedException e )
   {
   out.println( "some other thread woke me prematurely." )
   }

Setting Priority

Java priorities are in the range Thread.MIN_PRIORITY ( 1 ) to Thread.MAX_PRIORITY ( 10 ). The bigger the number, the better the access to the CPU a thread has.
// Bump up a thread's priority to the cpu
// one notch above the usual.
thread.setPriority( Thread.NORM_PRIORITY + 1 );

// Drop up the thread's priority two notches below
// where it is now.
thread.setPriority( thread.getPriority() - 2 );

Threads of equal priority are not necessarily scheduled round-robin style. One Thread can hog the CPU indefinitely squeezing out all the other Threads of equal priority even if the Threads call yield every once in a while to give the other Threads of equal priority a kick at the cat.

You may starve Swing so it never gets a chance to paint anything, even if you are on a separate Thread.

Death Watch/Stopping a Thread

If you want to wait for another thread to die, you can put yourself to sleep until it does by issuing a join. It comes in two flavours with and without a timeout. The name may sound odd for a deathwatch function. Here are two ways you can think about it to remember it.
  1. I will join you again after death, even though we part our ways for now.
  2. Alternatively, there are two threads and then there is only one after the join completes. You can think of join as somehow that it merged/joined the two threads into one. Don’t try to join the current thread.
Likely this is just quirky ancient Unix terminology living on. Getting a Thread to stop and waiting for it to die are slightly tricky. I have written a class called com.mindprod.common17.StoppableThread (download) you can use. It comes with source for you to create variants. It is well-commented to help you figure out how it works.

Current Thread

Sometimes you want to operate on the thread that is running now, say to bump up its current priority. You don’t do this with this.setPriority(). You must first get a handle on the 
// Get reference to the thread running this
// code right now.
Thread runningNow = Thread.currentThread();

Synchronized: Preventing Simultaneous Access

You also use the synchronized keyword to control simultaneous access. This kind of coding is incredibly tricky. You really have to know what you are doing to avoid bugs. Here is a very simple example to prevent two threads from executing the same hunk of code at once. They will automatically queue up to use it 

The lock part of every Object is called the monitor.

Note that the exact same critical code section may be executing simultaneously so long as it locks on different objects. You don’t always lock on this.

Because synchronized blocks can be nested, it is possible for thread to lock multiple objects at once. Then you have the potential for deadlock. If thread a has object 1 locked and wants object 2, and thread b has object 2 locked and wants object 1, they will stare at each other, waiting indefinitely in a Mexican standoff, sometimes called a deadly embrace. One way to avoid this is to always lock your objects is the same canonical order, always 1 before 2 using some convention you concoct to determine the standard order.

If you wanted two different critical sections to be able to execute simultaneously on the same object, to maximise speed in a multi-CPU machine or in critical sections that do i/o, you would need to create an auxiliary dummy locking object appended to (referenced by) the main object for the second critical region to use for its synchronized lock object, typically of type Object.

Once you understand these basics, you can go on to more complex tasks like co-operating producer-consumer threads that wait on each other and ways of allowing simultaneous read of a structure but only single-thread update.

Further, any variables that more than one thread might be changing have to be marked volatile to warn other threads to always look for a fresh copy of the value rather than relying on a their own cached copy.

Rendezvous

You don’t use Thread methods to rendezvous, but rather methods of Object, such as wait, notify and notifyAll. The use of these tools in the subject of an entire book. Imagine a simulated barbershop where customers wait, and when a barber is free, one of the waiting customers is notified. If there are plenty of free barbers, there is no waiting. Customers call wait() when all barbers are busy. And a barber who is free calls notify() to wake up one of the waiting customers.

With wait, you first must gain a lock on an object with synchronized, then you check if you really need to wait. If you do, then you call Object.wait() on the lock object. This puts your Thread to sleep, and releases the lock so that other threads might have it. Eventually some other thread awakens you from your slumber by calling Object.notify() or Object.notifyAll() on the lock object. You wake up then get in line waiting the reacquire the lock. When you finally do, you continue execution. In other words, you wait for some other thread to complete some work and notify you when it is done. The notifier thread needs to own the lock to be able to call notify, and it must release the lock before any of the waiting threads will be able to resume.

Most of the time in all this, the object is not kept locked. It is only locked for short periods to check if waiting is really necessary and do the wait or notify.

Volatile

You can think of volatile as a sort of streamlined form of sharing variables between threads that does not require locking or synchronizing in time. A thread never blocks to access a volatile variable, it just takes some extra time to access it. Note that synchronized locking is done on entire objects. Volatile applies to individual fields in those objects.

You might say that synchronized in for updating related groups of fields, where volatile is for updating independent single fields.

Particularly in a multi-CPU situation, you have a problem with caching. Each CPU keeps copies of variables in registers and in various hardware RAM caches. If another CPU changes a variable, it may automatically refresh the other CPU s' caches, but it certainly won’t automatically refresh any other CPU ’s registers. This means a CPU may be using a stale copy of a variable’s value and not know it. When you declare a variable volatile it warns the compiler to generate code to fetch the value freshly from RAM every time it is needed, even if it already has a copy it has not recently changed itself sitting in a register. Further, it warns the compiler to generate code to store the value into RAM every time it is changed so that other threads will immediately see the new value.

The same problem happens with less frequency in a single CPU system since each thread has its own virtual set of registers.

Despite what you may read elsewhere, volatile is not sufficient to make x++ into an atomic operation. Patricia Shanahan proved this experimentally. atomic means indivisible, not high-powered. Even with if x were declared Volatile, the thread will not necessarily get to complete the load, add, store in one operation without some other thread meddling with the x variable.

I have heard conflicting stories on just how synchronized and volatile mesh. It is safe to use them together: a volatile reference in a synchronized block. Some say you can use synchronized without volatile, but not volatile without synchronized in at least one of the threads. Others say you can use volatile on its own as well.

It seems to me, you would be safest to declare any variable examined by different threads as volatile whether you do all access inside synchronized or not. However, this is probably belt and suspenders, and might generate unnecessarily slow code. If I were designing the system, volatile would only be needed when there is some unsynchronized access. Experiments are not enough. That determines behaviour with only one compiler-JVM combination. Someday I will wade through the specs to find out how these keywords are supposed to work.

I presume when you enter a synchronized block the compiler freshly loads all values it needs, and when you exit it makes sure all are stored so that other CPUs (Central Processing Units) can see the new value. While it is inside the block it need not treat all variables as automatically volatile, since no other critical code is running. If someone can confirm or refute this assumption, please let me know.

Working with unsynchronized volatile data is very difficult to get solidly right. Treat it with just as much caution as you would unprotected volatile variables in a multi-threaded C or assembly language program. Reserve it for these few situations:

  1. Very simple one way communication, especially announcements e.g. that it is time to shut down operations.
  2. Building synchronization infrastructure, such as barriers. In any case this has to be done very carefully, with a large dose of suspicion.
  3. Writing test cases for multiprocessor systems.
The rest of the time, use synchronized blocks and mutex-protected critical regions since they are easier to think about and get right.

The problem is misuse of these features creates very subtle bugs that may not show up for days, or only when run on certain machines. You really do need a deep understanding of this, something I do not have yet. Unfortunately, trying to escape learning by being overly conservative also imparts a big speed penalty.

Thread Gotchas

Thread programming is incredibly tricky. Code will work most of the time then mysteriously fail after days of working fine. Code may work fine then fail as soon as you feed it to an optimising compiler, (likely missing volatile declarations). You have to be totally paranoid about Thread interactions. Everything happens much faster than it does in the real world, so that one in a billion events happen almost immediately. Here are some things to watch out for:

java.util.concurrent

This is a gross oversimplification of what java.util.concurrent does, however it might be a useful framework to use to dive in to the detail. You write little hunks of code conforming to an interface, then queue them up to be scheduled concurrently. There are three interfaces.

  1. Runnable with a run method. This is the simplest.
  2. Callable with a call method. This lets you return a single object.
  3. Future with its get method. It also has methods to poll the task to see how it is doing and to cancel it.

Debugging

If your threads don’t interact, there are two main errors you are likely to make:
  1. Tying up the main event processing thread either by putting it to sleep or giving it some onerous task. You should do those things on some other thread or user a Timer.
  2. Poking a Swing widget’s methods with something other than the main event processing thread. Swing is not thread-safe. You must use SwingUtilities. invokeLater, or EventQueue. invokeLater for all your manipulations from some other thread. There are a few exceptions.
So how do you catch yourself when you have accidentally made one of these two errors?

If you have an Applet, convert it into a hybrid that can also be run as an application. For details how see Applet. When a GUI is running, most of the time it should be idle, just waiting for the next event. If you hit Ctrl-Break (Ctrl-\ in Linux?) in the console window, it will interrupt and tell you what all the threads were doing. If the event thread is busy running application code something is amiss. Also monitor some known well-behaved GUI apps so you get an idea the sort of behaviour you should find. You will be surprised just how many threads are in there.

To catch yourself pestering Swing from the wrong thread try the ThreadCheckingRepaintManager. It checks that all repaint events came from the event thread. This won’t catch all your blunders, but it will catch most of them.

If your threads do interact, writing bug free code is extremely difficult. Your code will work most of time and then unexpectedly freeze during the big demo. You have to write the code using pure logic and paranoia, not just trying things and testing. As much as possible, use packages to handle your thread interaction problems. The authors of these packages specialise in the arcane art. Further, there are thousands of eyes checking the package for flaws.

Java version 1.5 or later has a rich set of thread handling classes, with even more goodies added in 1.6. You will want to write for Java version 1.6 or later for any multi-thread program.
Wherever possible, use them in preference to your own code. Keep in mind that things that could only happen once in a billion times will happen twice a second in a computer.

Let me repeat that for emphasis, the practical solution to bugs is to throw out as much of your home-brew Thread logic as possible and replace it with standard library code from the java.util.concurrent package.

This code will be much higher quality than anything you will be able to write because:

  1. It is being exercised in thousands of other applications. There are thus thousands of eyes peeled for bugs besides yours.
  2. It was written by the world’s acknowledged best thread expert, Doug Lea.

Books

book cover recommend book⇒Java Concurrency in Practiceto book home
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.
Australian flag abe books anz abe books.co.uk UK flag
Chinese flag amazon.cn amazon.co.uk UK flag
German flag abe books.de abe books.ca Canadian flag
German flag amazon.de amazon.ca Canadian flag
Spanish flag amazon.es Chapters Indigo Canadian flag
Spanish flag iberlibro.com abe books.com American flag
French flag abe books.fr amazon.com American flag
French flag amazon.fr Barnes & Noble American flag
Italian flag abe books.it Google play American flag
Italian flag amazon.it O’Reilly Safari American flag
India flag junglee.com Powells American flag
UN flag Kobo other stores UN flag
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.
book cover recommend book⇒Concurrent Programming in Java(TM): Design Principles and Patterns, third editionto book home
by Douglas Lea 978-0-321-25617-1 paperback
publisher Addison-Wesley
published 2006-05-19
This book is not in stock at any of the major online bookstores. Try looking for it with a bookfinder. 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).
book cover recommend book⇒Java Threads, third editionto book home
by Scott Oaks, Henry Wong 978-0-596-00782-9 paperback
publisher O’Reilly recommended 978-1-4493-6666-7 eBook
published 2004-09-10 B00BIRRRZA kindle
An introductory book with good examples. Not as deep as you would usually expect from O’Reilly.
Australian flag abe books anz abe books.co.uk UK flag
Chinese flag amazon.cn amazon.co.uk UK flag
German flag abe books.de abe books.ca Canadian flag
German flag amazon.de amazon.ca Canadian flag
Spanish flag amazon.es Chapters Indigo Canadian flag
Spanish flag iberlibro.com abe books.com American flag
French flag abe books.fr amazon.com American flag
French flag amazon.fr Barnes & Noble American flag
Italian flag abe books.it Google play American flag
Italian flag amazon.it O’Reilly Safari American flag
India flag junglee.com Powells American flag
UN flag Kobo other stores UN flag
book cover recommend book⇒Thinking In Java, fourth editionto book home
by Bruce Eckel 978-0-13-187248-6 paperback
birth 1957-07-08 age: 57
publisher Prentice Hall
published 2006-02-20
read online. Good if you want to understand the philosophy behind Java. It does not cover Java 1.5 or later, e.g. enums, generics, for:each loops, annotations.
Australian flag abe books anz abe books.co.uk UK flag
Chinese flag amazon.cn amazon.co.uk UK flag
German flag abe books.de abe books.ca Canadian flag
German flag amazon.de amazon.ca Canadian flag
Spanish flag amazon.es Chapters Indigo Canadian flag
Spanish flag iberlibro.com abe books.com American flag
French flag abe books.fr amazon.com American flag
French flag amazon.fr Barnes & Noble American flag
Italian flag abe books.it Google play American flag
Italian flag amazon.it O’Reilly Safari American flag
India flag junglee.com Powells American flag
UN flag Kobo other stores UN flag
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.
book cover recommend book⇒Java Thread Programmingto book home
by Paul Hyde 978-0-672-31585-5 paperback
publisher Sams
published 1999-08-30
Australian flag abe books anz abe books.co.uk UK flag
Chinese flag amazon.cn amazon.co.uk UK flag
German flag abe books.de abe books.ca Canadian flag
German flag amazon.de amazon.ca Canadian flag
Spanish flag amazon.es Chapters Indigo Canadian flag
Spanish flag iberlibro.com abe books.com American flag
French flag abe books.fr amazon.com American flag
French flag amazon.fr Barnes & Noble American flag
Italian flag abe books.it Google play American flag
Italian flag amazon.it O’Reilly Safari American flag
India flag junglee.com Powells American flag
UN flag Kobo other stores UN flag
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.
book cover recommend book⇒Taming Java Threadsto book home
by Allen Holub 978-1-893115-10-1 paperback
birth 1955 age: 59 B001GMAPVA kindle
publisher Apress
published 2000-06-01
Australian flag abe books anz abe books.co.uk UK flag
Chinese flag amazon.cn amazon.co.uk UK flag
German flag abe books.de abe books.ca Canadian flag
German flag amazon.de amazon.ca Canadian flag
Spanish flag amazon.es Chapters Indigo Canadian flag
Spanish flag iberlibro.com abe books.com American flag
French flag abe books.fr amazon.com American flag
French flag amazon.fr Barnes & Noble American flag
Italian flag abe books.it Google play American flag
Italian flag amazon.it O’Reilly Safari American flag
India flag junglee.com Powells American flag
UN flag Kobo other stores UN flag
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Learning More

Oracle’s Javadoc on java.lang.Runnable class : available:
Oracle’s Javadoc on java.lang.Thread.setDefaultUncaughtExceptionHandler : available:
Oracle’s Javadoc on java.lang.Thread class : available:
Oracle’s Javadoc on java.util.concurrent.atomic.AtomicLong class : available:
Oracle’s Javadoc on java.util.concurrent.atomic.AtomicReference class : available:
Oracle’s Javadoc on java.util.concurrent.BlockingQueue class : available:
Oracle’s Javadoc on java.util.concurrent.Callable class : available:
Oracle’s Javadoc on java.util.concurrent.ExecutorService.newFixedThreadPool : available:
Oracle’s Javadoc on java.util.concurrent.ExecutorService class : available:
Oracle’s Javadoc on java.util.concurrent.ForkJoinPool class : available:
Oracle’s Javadoc on java.util.concurrent.Future class : available:
Oracle’s Javadoc on java.util.concurrent.LinkedBlockingQueue class : available:
Oracle’s Javadoc on java.util.concurrent package : available:
Oracle’s Javadoc on java.util.concurrent.Semaphore class : available:
Oracle’s Javadoc on java.util.concurrent.ThreadPoolExecutor class : available:
Oracle’s Javadoc on java.util.concurrent.CyclicBarrier class : available:
Oracle’s Javadoc on java.util.Queue interface : available:

This page is posted
on the web at:

http://mindprod.com/jgloss/thread.html

Optional Replicator mirror
of mindprod.com
on local hard disk J:

J:\mindprod\jgloss\thread.html
logo
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.
no blog for this page
IP:[65.110.21.43]
Your face IP:[54.227.160.102]
You are visitor number