Priorities

Priorities

The priority of a thread tells the scheduler how important this thread is. If there are a number of threads blocked and waiting to be run, the scheduler will run the one with the highest priority first. However, this doesn't mean that threads with lower priority don't get run (that is, you can't get deadlocked because of priorities). Lower priority threads just tend to run less often.

You can read the priority of a thread with getPriority( ) and change it with setPriority( ). The form of the prior "counter" examples can be used to show the effect of changing the priorities. In this applet you'll see that the counters slow down as the associated threads have their priorities lowered:

Ticker2 follows the form established earlier in this chapter, but there's an extra TextField for displaying the priority of the thread and two more buttons for incrementing and decrementing the priority.

Also notice the use of yield( ), which voluntarily hands control back to the scheduler. Without this the multithreading mechanism still works, but you'll notice it runs slowly (try removing the call to yield( )!). You could also call sleep( ), but then the rate of counting would be controlled by the sleep( ) duration instead of the priority.

The init( ) in Counter5 creates an array of 10 Ticker2s; their buttons and fields are placed on the form by the Ticker2 constructor. Counter5 adds buttons to start everything up as well as increment and decrement the maximum priority of the threadgroup. In addition, there are labels that display the maximum and minimum priorities possible for a thread and a TextField to show the thread group's maximum priority. (The next section will fully describe thread groups.) Finally, the priorities of the parent thread groups are also displayed as labels.

When you press an "up" or "down" button, that Ticker2's priority is fetched and incremented or decremented accordingly.

When you run this program, you'll notice several things. First of all, the thread group's default priority is 5. Even if you decrement the maximum priority below 5 before starting the threads (or before creating the threads, which requires a code change), each thread will have a default priority of 5.

The simple test is to take one counter and decrement its priority to one, and observe that it counts much slower. But now try to increment it again. You can get it back up to the thread group's priority, but no higher. Now decrement the thread group's priority a couple of times. The thread priorities are unchanged, but if you try to modify them either up or down you'll see that they'll automatically pop to the priority of the thread group. Also, new threads will still be given a default priority, even if that's higher than the group priority. (Thus the group priority is not a way to prevent new threads from having higher priorities than existing ones.)

Finally, try to increment the group maximum priority. It can't be done. You can only reduce thread group maximum priorities, not increase them.

Thread groups

All threads belong to a thread group. This can be either the default thread group or a group you explicitly specify when you create the thread. At creation, the thread is bound to a group and cannot change to a different group. Each application has at least one thread that belongs to the system thread group. If you create more threads without specifying a group, they will also belong to the system thread group.

Thread groups must also belong to other thread groups. The thread group that a new one belongs to must be specified in the constructor. If you create a thread group without specifying a thread group for it to belong to, it will be placed under the system thread group. Thus, all thread groups in your application will ultimately have the system thread group as the parent.

The reason for the existence of thread groups is hard to determine from the literature, which tends to be confusing on this subject. It's often cited as "security reasons." According to Arnold & Gosling, "Threads within a thread group can modify the other threads in the group, including any farther down the hierarchy. A thread cannot modify threads outside of its own group or contained groups." It's hard to know what "modify" is supposed to mean here. The following example shows a thread in a "leaf" subgroup modifying the priorities of all the threads in its tree of thread groups as well as calling a method for all the threads in its tree.

In main( ), several ThreadGroups are created, leafing off from each other: x has no argument but its name (a String), so it is automatically placed in the "system" thread group, while y is under x and z is under y. Note that initialization happens in textual order so this code is legal.

Two threads are created and placed in different thread groups. TestThread1 doesn't have a run( ) method but it does have an f( ) that modifies the thread and prints something so you can see it was called. TestThread2 is a subclass of TestThread1 and its run( ) is fairly elaborate. It first gets the thread group of the current thread, then moves up the heritage tree by two levels using getParent( ). (This is contrived since I purposely place the TestThread2 object two levels down in the hierarchy.) At this point, an array of handles to Threads is created using the method activeCount( ) to ask how many threads are in this thread group and all the child thread groups. The enumerate( ) method places handles to all of these threads in the array gAll, then I simply move through the entire array calling the f( ) method for each thread, as well as modifying the priority. Thus, a thread in a "leaf" thread group modifies threads in parent thread groups.

The debugging method list( ) prints all the information about a thread group to standard output and is helpful when investigating thread group behavior. Here's the output of the program:

Not only does list( ) print the class name of ThreadGroup or Thread, but it also prints the thread group name and its maximum priority. For threads, the thread name is printed, followed by the thread priority and the group that it belongs to. Note that list( ) indents the threads and thread groups to indicate that they are children of the un-indented thread group.

You can see that f( ) is called by the TestThread2 run( ) method, so it's obvious that all threads in a group are vulnerable. However, you can access only the threads that branch off from your own system thread group tree, and perhaps this is what is meant by "safety." You cannot access anyone else's system thread group tree.

Controlling thread groups

Putting aside the safety issue, one thing thread groups do seem to be useful for is control: you can perform certain operations on an entire thread group with a single command. The following example demonstrates this and the restrictions on priorities within thread groups. The commented numbers in parentheses provide a reference to compare to the output.

The output that follows has been edited to allow it to fit on the page (the java.lang. has been removed) and to add numbers to correspond to the commented numbers in the listing above.

All programs have at least one thread running, and the first action in main( ) is to call the static method of Thread called currentThread( ). From this thread, the thread group is produced and list( ) is called for the result. The output is:

You can see that the name of the main thread group is system, and the name of the main thread is main, and it belongs to the system thread group.

The second exercise shows that the system group's maximum priority can be reduced and the main thread can have its priority increased:

The third exercise creates a new thread group, g1, which automatically belongs to the system thread group since it isn't otherwise specified. A new thread A is placed in g1. After attempting to set this group's maximum priority to the highest level and A's priority to the highest level, the result is:

Thus, it's not possible to change the thread group's maximum priority to be higher than its parent thread group.

The fourth exercise reduces g1's maximum priority by two and then tries to increase it up to Thread.MAX_PRIORITY. The result is:

You can see that the increase in maximum priority didn't work. You can only decrease a thread group's maximum priority, not increase it. Also, notice that thread A's priority didn't change, and now it is higher than the thread group's maximum priority. Changing a thread group's maximum priority doesn't affect existing threads.

The fifth exercise attempts to set a new thread to maximum priority:

The new thread cannot be changed to anything higher than the maximum thread group priority.

The default thread priority for this program is 6; that's the priority a new thread will be created at and where it will stay if you don't manipulate the priority. Exercise six lowers the maximum thread group priority below the default thread priority to see what happens when you create a new thread under this condition:

Even though the maximum priority of the thread group is 3, the new thread is still created using the default priority of 6. Thus, maximum thread group priority does not affect default priority. (In fact, there appears to be no way to set the default priority for new threads.)

After changing the priority, attempting to decrement it by one, the result is:

Only when you attempt to change the priority is the thread group's maximum priority enforced.

A similar experiment is performed in (8) and (9), in which a new thread group g2 is created as a child of g1 and its maximum priority is changed. You can see that it's impossible for g2's maximum to go higher than g1's:

Also notice that g2 is automatically set to the thread group maximum priority of g1 as g2 is created.

After all of these experiments, the entire system of thread groups and threads is printed out:

So because of the rules of thread groups, a child group must always have a maximum priority that's less than or equal to its parent's maximum priority.

The last part of this program demonstrates methods for an entire group of threads. First the program moves through the entire tree of threads and starts each one that hasn't been started. For drama, the system group is then suspended and finally stopped. (Although it's interesting to see that suspend( ) and stop( ) work on entire thread groups, you should keep in mind that these methods are deprecated in Java 1.2.) But when you suspend the system group you also suspend the main thread and the whole program shuts down, so it never gets to the point where the threads are stopped. Actually, if you do stop the main thread it throws a ThreadDeath exception, so this is not a typical thing to do. Since ThreadGroup is inherited from Object, which contains the wait( ) method, you can also choose to suspend the program for any number of seconds by calling wait(seconds * 1000). This must acquire the lock inside a synchronized block, of course.

The ThreadGroup class also has suspend( ) and resume( ) methods so you can stop and start an entire thread group and all of its threads and subgroups with a single command. (Again, suspend( ) and resume( ) are deprecated in Java 1.2.)

Thread groups can seem a bit mysterious at first, but keep in mind that you probably won't be using them directly very often.