For the most part, green threads are scheduled exactly as we discussed earlier. In most implementations of green threads, there is no notion of round-robin scheduling, so green threads will not automatically timeslice. Scheduling is entirely the responsibility of the virtual machine, and the virtual machine usually changes the currently running thread only when another thread of higher priority becomes runnable (or when the currently running thread blocks). However, this is not a requirement of the Java specification, and a green-thread implementation could conceivably include a timer to do round-robin scheduling.

The reference implementation of the green-thread model uses priority inheritance, so that the priority of a thread will be temporarily raised if it is holding a lock on which a higher-priority thread is waiting.

Depending on the operating system, however, green threads may not exhibit a precise scheduling behavior: there may be a very small period of time during which a lower-priority thread is running even though a higher-priority thread may want to run.

As an example, consider what happens when a Java thread reads data from a socket that has no data. The expectation is that the thread will block—but the virtual machine itself cannot afford to block. Hence, the virtual machine must have some way of being notified when data is ready on the socket, and only then can it allow the thread to read the data on the socket. In most operating systems, that’s possible using asynchronous I/O: when data is available on the socket, the virtual machine will receive a signal that will interrupt what it is presently doing. In response to the signal, the virtual machine can run the thread that wants to read the data.

In some operating systems, however, there is no facility for asynchronous I/O. In those cases the virtual machine must periodically poll the socket to see if data is available. This polling usually happens periodically, perhaps every few milliseconds. When data is available, then the virtual machine may schedule the thread that wants to read the data.

Now, say that a high-priority thread is waiting for data from the socket, and meanwhile, a lower-priority thread is performing some other calculation. If the virtual machine is dependent on polling the socket to see when data is ready, then there will be a very small window of time after data arrives on the socket and before the virtual machine next polls the socket. During this time, the lower-priority thread will still be executing, even though the higher-priority thread should be the one that is executing.

Situations like this almost never affect an actual program—the delay is very slight, and there are many other factors that may have influenced the program anyway: what if the pending data had been delayed even longer in coming across the network? What if another process on the machine prevented the Java application from running for a few microseconds? Java is not a real-time platform, so the scheduling anomaly that we’ve just described is unlikely to have any impact on a Java program.

However, be aware that this is one reason why even if one thread in the Java virtual machine causes another thread to become unblocked there may be a delay before the higher-priority thread actually runs. Say that we run the following code fragment in a low-priority thread:

public class LockTest {
    Object someObject = new Object();
    class ThreadA extends Thread {
        ThreadA() {
            setPriority(Thread.MAX_PRIORITY);
        }
        public void run() {
            synchronized(someObject) {
                someObject.wait();
            }
            someObject.methodA();
        }
    }
    class ThreadB extends Thread {
        ThreadB() {
            setPriority(Thread.NORM_PRIORITY);
        }
        public void run() {
            synchronized(someObject) {
                someObject.notify();
            }
            someObject.methodB();
        }
    }
    static void main(String args[]) {
        new ThreadA().start();
        new ThreadB().start();
    }
}

In this example, we’re starting two threads: ThreadA, which has a priority of 10, and ThreadB, which has a priority of 5. Since we start ThreadA first, the expectation is that it will begin its run() method and block on the wait() method. Then ThreadB will start and notify ThreadA. In a strict priority model, ThreadA will wake up, preempt ThreadB, and execute the methodA() method. Then ThreadB will execute the methodB() method. However, we cannot assume that the priority scheduler of the green-thread model is strict enough to ensure that the methodA() method will be called before the methodB() method is called, even though that will happen in the vast majority of cases.

In the Windows native threads model, the operating system takes an important role in thread scheduling. In particular, the operating system schedules threads just like it schedules processes. That means that threads are scheduled on a preemptive, priority-based mechanism, just as we’d hope, but there are a few complications added to the generic model we described earlier.

To begin, only seven priorities are recognized by the Windows operating system; these seven priorities must map onto the eleven Java thread priorities. Since one of these priorities is typically reserved for the internal 0-level Java thread priority, the end result is that the ten programmable Java thread priorities must map onto six Windows platform priorities. Different virtual machines will do this differently, but one common implementation performs the mapping listed in Table 6.1.

THREAD_PRIORITY_IDLE

THREAD_PRIORITY_LOWEST

THREAD_PRIORITY_LOWEST

THREAD_PRIORITY_BELOW_NORMAL

THREAD_PRIORITY_BELOW_NORMAL

THREAD_PRIORITY_NORMAL

THREAD_PRIORITY_ABOVE_NORMAL

THREAD_PRIORITY_ABOVE_NORMAL

THREAD_PRIORITY_HIGHEST

THREAD_PRIORITY_HIGHEST

THREAD_PRIORITY_TIME_CRITICAL

On this implementation, having a thread of priority 3 and a thread of priority 4 will be the same as having two threads with a priority of 4.

In addition to seven priority levels, the Windows operating system also has five scheduling classes, and a thread in Windows is actually scheduled as a combination of its priority and its scheduling class. However, scheduling classes for threads are not easy to change, so they do not factor into a system where priorities can be changed dynamically by the programmer.

A second complication arises on this platform because the priority that a programmer can assign to a thread (that is, one of the seven platform-specific priorities) is only one piece of the information that the operating system uses to determine the absolute priority of a thread. There are other things that can affect the priority of a thread:

The upshot of all this is that it is very difficult to guarantee explicit ordering of thread execution on Windows platforms. However, because the operating system ensures that threads do not starve and that equal-priority threads timeslice, this is not usually a problem.

Scheduling of Solaris native threads is a little complex, but it follows the same principles that we’ve already seen. From the perspective of any particular LWP, the scheduling follows the green-thread model. At any point in time, an LWP will run the highest priority thread available. An LWP will not perform any timeslicing among the eligible threads: just as in the green-thread model, once an LWP selects a thread to run, it will continue to run that thread until a higher-priority thread becomes available. There is a difference, however, in how an LWP handles a thread that blocks; we’ll look into that a little further on. There is a one-to-one mapping between the threads that an LWP can run and threads in a Java program; hence, in a Java virtual machine that has a single LWP, scheduling is very much like the green-thread model.

However, programs written with Solaris native threads typically have multiple LWPs, each of which is scheduled by the operating system. Although LWPs themselves have a priority, this priority is unknown to the Java programmer and is unaffected by the priority of the thread that the LWP has selected to run. Hence, all LWPs in the virtual machine have essentially the same priority, and—just like on a Windows platform—this priority is subject to periodic adjustment based on how recently the LWP has run. Thus, LWPs will timeslice among themselves.

Therefore, when an LWP runs, it runs the thread with the highest priority. The LWP eventually loses its timeslice, and another LWP runs. This second LWP chooses the remaining thread with the highest priority and runs that thread. This process continues throughout the lifetime of the virtual machine.

Consider the effects of this process in a virtual machine that has created two threads when given two LWPs by the operating system. Assume that both threads have a priority of 5. When the first LWP comes along, it picks (seemingly arbitrarily) one of the priority 5 threads and starts running it. Eventually, the LWP loses its timeslice; the second LWP comes along and picks the remaining priority 5 thread and begins running that thread. When it loses its timeslice and the first LWP starts running again, the first thread is run. And so it goes—the two threads are timesliced, because each LWP is being given a timeslice by the operating system.

Now, say that there are three threads of equal priority and only two LWPs. In this case, the first two threads will timeslice, and the third thread will not get to run at all (at least, not until one of the first two threads blocks or exits). Again, this is consistent with the scheduling model that we learned about earlier: a thread is subject to starvation unless other threads of the same or higher priority will all eventually block. An LWP, once it has selected a thread, will run that thread until the thread blocks or until a higher-priority thread becomes available.

So, suppose we have two threads and two LWPs, but this time, one thread has a priority of 5 and one has a priority of 4. Interestingly enough, these threads will still timeslice, which means that there will be times when the priority 4 thread is running even though the priority 5 thread is not blocked. When the first LWP comes along, it selects the priority 5 thread and runs that thread. When the second LWP begins to run, it must select a thread; as far as it is concerned, the only available thread is the priority 4 thread, since the priority 5 thread has already been assigned to an LWP. Hence, this second LWP begins running the priority 4 thread, even through the priority 5 thread is not blocked. The two threads timeslice in this example.

We do not mean to imply here that because the priority 5 thread has been running on a particular LWP, it is forever bound to that LWP. Such a situation (known as bound threads ) is possible in a Solaris program, but most implementations of the Java virtual machine use unbound threads. The priority 5 thread may be displaced from its LWP when a higher-priority thread becomes runnable, at which point the priority 5 thread goes back into the pool of waiting threads. When the LWP running the priority 4 thread runs again, it will then displace the priority 4 thread in favor of the priority 5 thread because the priority 5 thread is not presently assigned to any LWP.

The rule of thumb, then, is that N number of LWPs in a Java virtual machine will be running (and timeslicing) the N threads with highest priority in the virtual machine (even if those threads have unequal priorities).

Finally, we note that Solaris native threads use priority inheritance.

How many LWPs does the virtual machine have? The answer varies according to the rules we will lay out here. To answer this question, we must delve into the details of the Solaris thread library a little more.

The Solaris thread model follows the Java threading API fairly well. In the thread library itself, there is the notion of thread priorities. This means that the actual scheduling of threads onto specific LWPs can be handled by the Solaris thread library itself, following the priority-based rules that the virtual machine expects. To the programmer, this scheduling is identical to when the virtual machine schedules using green threads.

The number of LWPs is controlled by the Solaris thread library according to the following guidelines:

The virtual machine thus never creates new LWPs; that is handled by the operating system and the Solaris thread library. That means that the number of LWPs that exist in the Java virtual machine will be equal to the number of threads in the Java virtual machine that have ever been simultaneously blocked, plus one. In practice, this means that a typical Java application may start with five to seven LWPs, since during the initialization of the virtual machine, there may be four to six LWPs that are simultaneously blocked.

There are therefore usually at least two LWPs available to the Java program; the remaining LWPs tend to be blocked in the course of executing threads that are internal to the virtual machine itself. Hence, you can often rely on two threads of your program to be scheduled onto LWPs and to timeslice between them, even if they are not the same priority.

On a single-processor machine, this number of LWPs is usually sufficient. If it is insufficient—that is, if you create threads that block and tie up the existing LWPs—then new LWPs will be created on demand. If there are one or more unblocked threads in your Java program, there will always be at least one LWP to run those threads.

On a multiprocessor machine, however, this may not be a sufficient number of LWPs, especially if the threads in the Java program are CPU intensive and rarely block. If you have a machine with eight CPUs that’s behaving as a calculation server and you only have two LWPs available, you will not see the scaling that you desire, no matter how many threads you create. In order to get the most benefit from this machine, you need at least eight available LWPs—one for each CPU—so that you can run eight CPU-intensive threads at the same time.

In this case, you must call the operating system-specific library in order to tell it that you want eight (or however many you desire) LWPs. We’ll show an example of how to do that at the end of this section, but it involves using a native method to call the thr_setconcurrency() function of the Solaris thread library in order to create enough LWPs. Depending on your perspective, this can seem either very complicated or very cool.

This seems rather complicated. Do I really need to bother with it? Probably not. If you have a single-CPU machine, you definitely won’t see a benefit from it—in fact, you’ll slightly impede the performance of your machine, because you’ll have too many LWPs competing for the CPU. If you have multiple CPUs, you’ll only see a benefit if you have multiple threads that spend a significant amount of time executing code without blocking. If you write a chat server, then more LWPs isn’t going to help you: while you might have a thread for each client attached to the server, those threads spend most of their time blocked, waiting for input from the clients. In that case, the thread library will create enough LWPs for you: it will create a number sufficient to hold all simultaneously blocked threads, and when a thread unblocks, it will already be on an LWP so that it can process its request.

So you really need to worry about the number of available LWPs only when you write something that has multiple CPU-intensive threads.

This seems pretty cool, but how do I know how many LWPs I need? This is a hard question to answer. Assuming that you have enough threads to demand it, the answer is that you need as many LWPs as you have threads that will be blocked simultaneously, plus one LWP for each thread that you want to run simultaneously. You’ll see the best throughput when the number of running threads is equal to the number of CPUs on the machine. If there are any less, there will be idle CPUs that could be doing more work. If there are more, the LWPs will compete for CPU time.

Of course, there may be other things happening on the machine, which may lead you to want fewer LWPs than CPUs so that other programs can get a sufficient amount of CPU time. But there’s never really an advantage to having more LWPs than there are CPUs—even if you have hundreds of threads that you want to timeslice, you can accomplish that better by introducing some scheduling techniques into your program rather than creating hundreds of LWPs. Despite their name, LWPs still require system resources, and they are much more resource-intensive than are threads. A Java virtual machine on Solaris can easily handle thousands of threads, but not necessarily thousands of LWPs.