Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API
This month, I continue my four-part thread series by focusing on thread scheduling, the wait/notify mechanism, and thread interruption. You'll investigate how either a JVM or an operating-system thread scheduler chooses the next thread for execution. As you'll discover, priority is important to a thread scheduler's choice. You'll examine how a thread waits until it receives notification from another thread before it continues execution and learn how to use the wait/notify mechanism for coordinating the execution of two threads in a producer-consumer relationship. Finally, you'll learn how to prematurely awaken either a sleeping or a waiting thread for thread termination or other tasks. I'll also teach you how a thread that is neither sleeping nor waiting detects an interruption request from another thread.
Read the whole series on thread programming:
In an idealized world, all program threads would have their own processors on which to run. Until the time comes when computers have thousands or millions of processors, threads often must share one or more processors. Either the JVM or the underlying platform's operating system deciphers how to share the processor resource among threads—a task known as thread scheduling. That portion of the JVM or operating system that performs thread scheduling is a thread scheduler.
| Note |
|---|
| To simplify my thread scheduling discussion, I focus on thread scheduling in the context of a single processor. You can extrapolate this discussion to multiple processors; I leave that task to you. |
Remember two important points about thread scheduling:
Examine a program that creates two processor-intensive threads:
Listing 1: SchedDemo.java
// SchedDemo.java
class SchedDemo
{
public static void main (String [] args)
{
new CalcThread ("CalcThread A").start ();
new CalcThread ("CalcThread B").start ();
}
}
class CalcThread extends Thread
{
CalcThread (String name)
{
// Pass name to Thread layer.
super (name);
}
double calcPI ()
{
boolean negative = true;
double pi = 0.0;
for (int i = 3; i < 100000; i += 2)
{
if (negative)
pi -= (1.0 / i);
else
pi += (1.0 / i);
negative = !negative;
}
pi += 1.0;
pi *= 4.0;
return pi;
}
public void run ()
{
for (int i = 0; i < 5; i++)
System.out.println (getName () + ": " + calcPI ());
}
}
SchedDemo creates two threads that each calculate the value of pi (five times) and print each result. Depending upon how your JVM implementation
schedules threads, you might see output resembling the following:
CalcThread A: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread B: 3.1415726535897894
According to the above output, the thread scheduler shares the processor between both threads. However, you could see output similar to this:
CalcThread A: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread A: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread B: 3.1415726535897894 CalcThread B: 3.1415726535897894
The above output shows the thread scheduler favoring one thread over another. The two outputs above illustrate two general categories of thread schedulers: green and native. I'll explore their behavioral differences in upcoming sections. While discussing each category, I refer to thread states, of which there are four:
start() method has not yet been called.
start() completes, a thread becomes runnable whether or not that thread is running, that is, using the processor. Although many threads
might be runnable, only one currently runs. Thread schedulers determine which runnable thread to assign to the processor.
sleep(), wait(), or join() methods, when a thread attempts to read data not yet available from a network, and when a thread waits to acquire a lock,
that thread is in the blocked state: it is neither running nor in a position to run. (You can probably think of other times
when a thread would wait for something to happen.) When a blocked thread unblocks, that thread moves to the runnable state.
run() method, that thread is in the terminating state. In other words, the thread ceases to exist.
How does the thread scheduler choose which runnable thread to run? I begin answering that question while discussing green thread scheduling. I finish the answer while discussing native thread scheduling.
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
![]()
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq