In Java 6, why doesn't higher priority thread not run even if lower priority thread yields?

In the code below, I am trying to get the higher priority thread to run by yielding the lower priority thread. But it doesn't seem to work, the higher priority thread seems to run after lower priority thread finishes. Can anyone explain what I am doing wrong?

import java.util.ArrayList;
import java.util.List;

public class TestThreadPriority extends Thread {

    static List<String> messages = new ArrayList<String>();

    public void run() {
        Thread t = Thread.currentThread();
        int priority = t.getPriority();
        String name = t.getName();
        messages.add(name + ":" + priority);        
        Thread.yield();
        messages.add(name + ":" + priority);
    }

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Thread t = Thread.currentThread();
        t.setPriority(MIN_PRIORITY);
        int priority = t.getPriority();
        String name = t.getName();
        messages.add(name + ":" + priority);

        Thread tp1 = new TestThreadPriority();
        tp1.setPriority(MIN_PRIORITY);      
        Thread tp2 = new TestThreadPriority();
        tp2.setPriority(MAX_PRIORITY);      

        tp1.start();
        tp2.start();

        Thread.yield();
        messages.add(name + ":" + priority);

        for(int i = 0; i < messages.size(); i开发者_如何学JAVA++) {
            System.out.println((i+1) + ". " + messages.get(i));
        }
    }
}

Output is:

1. main:1
2. Thread-0:1
3. Thread-0:1
4. main:1
5. Thread-1:10
6. Thread-1:10

Any help is greatly appreciated.

Thanks, Quadir

I'd guess that your first thread has finished executing even before the second thread has started. Perhaps if your threads did some real work (or even just slept a bit) you'd see overlapping messages from the two threads.

Another problem with your code is that you are accessing messages from multiple threads without synchronizing.

You also should join with the two threads you've started before trying to print the contents of messages, to ensure that the threads you started have already logged their messages and that they don't try to modify the list while you're iterating over it to print it.

Once you've fixed all this, one final point is that both your threads are yielding, not just the lower priority thread. When the higher priority thread yields, it's perfectly reasonable that the lower priority thread gets some running time. Having a higher priority doesn't give you a monopoly. In your simplified code example the priority probably won't make much difference to what happens - it will be mostly down to chance as to which thread hits the yield statement first.

I read that the current running thread is always equal or highest priority thread in the thread pool. Is this statement wrong?

Yes, it is wrong. In fact, neither the Java Language Specification or the Java Virtual Machine Specification mentions thread priorities. And the javadoc for java.lang.Thread says (just) this:

Every thread has a priority. Threads with higher priority are executed in preference to threads with lower priority.

In fact Java's thread priority model is unspecified, and the impact of thread priorities is JVM, hardware and application specific. Some reasons your statement (above) can be incorrect are as follows:

• If the JVM is using multiple processors, you could reasonably expect high and low priority threads to be running simultaneously.

• If the only high priority thread calls yield(), a lower priority thread will start running.

• If a high priority thread blocks in a I/O call, it may not be resumed immediately on the I/O completing.

• Some JVM's implement time-slicing, and it is possible that a low-priority thread might be scheduled to run when the only high priority thread's time-slide finishes. (In reality, I don't know if this happens ... but arguably it is a good thing to do this to mitigate "priority inversion" problems.)

In practice, this all means that you should not rely on priorities to give you fine grained scheduling; e.g. by adjusting priorities up and down. And you certainly should not use priorities as a substitute for proper synchronization.