Threads: The Dirt

Thread: a shorthand for thread of control: a section of code executed independently of other threads of control within a single program. API

Theoretical States of a thread

Since problems were seen in the exact state of a thread, implementation specific states have now evolved to NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED and in java 1.5 we have a nested class Thread.State and Thread.getState(). For specifics, see the Thread.State API

Related term:

Useful method:

The Good

Parallelism: Issues in concurrent programming (reminder: concurrent - in progress at same time (same processor); parallel - execute simultaneously (multiple processors))

Parallel Algorithms: Take advantage of multiple processors

The Bad

Thread Management take a certain amount of overhead. Threads must be created, terminated, scheduled, and synchronized.

See also these resource sharing notes

The Ugly: Scheduling and Synchronizing

Starvation:

Whenever multiple threads compete for a scarce resource, there is a danger of starvation. With a bad choice of scheduling, some threads never have the opportunity to become the current running thread and suffer from CPU starvation.

A similar situation is theoretically possible when it comes to locks granted by the synchronized keyword. Lock starvation occurs when a particular thread attempts to acquire a lock and never succeeds because another thread is already holding the lock. This can be subtle: if there are six threads competing for the same lock, it is possible that each of the five threads will hold the lock for only 20 percent of the time, thus starving the sixth thread. A solution is making sure threads have equal priority.

Locking an Object (and here) The code segments within a program that access the same object from separate, concurrent threads are called critical sections. In the Java language, a critical section can be a block or a method and are identified with the synchronized keyword. The Java platform then associates a lock with every object that has synchronized code. More on locks when I discuss synchronization.

Deadlock

Look what I found! The Dining Philospher's as Duke's

Race Conditions:

A race condition occurs when the order of execution of any two threads may affect some variable or outcome in the program

And what about this:

Here is the output of running CatchDeath. Notice that I called stop, but it still was "running" enough to print the exception

This is all well and good ... actually it is all bad and terrible ... so Why JavaSoft is Deprecating Thread.stop?.


Here is a snippet of the Why Deprecated page. Also see Chapter 1 in Core Java Volume II, pages 45-49

Process Considerations

Synchronization

Here is the situation
  1. the husband thread begins to execute the deduct() method
  2. the husband thread confirms that the total in the account is more than the amount to deduct
  3. the wife thread begins to execute the deduct() method
  4. the wife thread confirms that the total in the account is more than the amount to deduct
  5. the wife thread performs the subtraction statement to deduct the amount, returns true, and the ATM dispenses her cash
  6. the husband thread performs the subtraction statement to deduct the amount, returns true, and the ATM dispenses his cash

The reason that there is a race condition is because the action of checking the account and changing the account status is not atomic.

Hopefully, with the two sources here we can be clear on synchronization.

Here it is if you don't have the link

Running his code gives

This shows a couple of things. First, that the method foobar could manipulate the variables mentioned in foo even though foo() is synchronized.

It also shows that being in a synchronized method does not stop any other methods in the class except other synchronized methods. The next test shows this, and, this is what we would expect
         This is also obvious since the scope of run() is infinite (the run() method executes in an infinite loop). So run() is always running even when you are in a synchronized method.

So, try a simple edit to make the foobar synchronized
synchronized void foobar() {
shows

So atomic is related to synchronized but be careful. The idea of atomic should be thought of as relative to each other. That is

Note that if the method declarations for all methods contain the synchronized keyword, the system associates a unique lock with every instance of the class. Whenever control enters a synchronized method, the thread that called the method locks the object whose method has been called. Other threads cannot call a synchronized method on the same object until the object is unlocked.

So, being in a synchronized method does lock the object from other threads if the other threads are calling synchronized methods and/or if all methods are synchronized.

The acquisition and release of a lock is done automatically and atomically by the Java runtime system. This ensures that race conditions cannot occur in the underlying implementation of the threads, thus ensuring data integrity. Synchronization isn't the whole story. The two threads must also be able to notify one another when they've done their job. (wait() and notifyAll())

Synchronization particulars

Priority Scheduling

Understanding Thread Priority SUN Tutorial

Thread Groups and Pools

ThreadGroup API , tutorial, developer.com
Pooling Threads SUN Tutorial

Concurrancy

Java 1.5 came out with some new capabilities for "high-level" concurrancy handling. See tutorial and the java.util.concurrent, java.util.concurrent.atomic and the java.util.concurrent.locks packages

Resources

Threaded code samples

FAQs on threads

FAQs all (thought it might help in general)

A couple of book chapters from Java Thread Programming

An example use: Building a Service Provider using JNDI and threads


These are no longer at the sites listed...I will look to see where they were moved
  • SUN's page specifically oriented to Multi-threaded issues (not just Java) and some papers on threads
  • Java Threads Whitepaper by Daniel J.Berg, and examples therein. SUN March 1996