Thread Priority in Java

Imagine a program that computes the pixels of a large image. A single thread would have to visit every row by itself. The program in this lesson takes a different approach. When the user clicks the Start button, it creates and starts a specified number of threads, and it gives each thread its own segment of the image to compute. The question this article answers is simple to state but easy to get wrong: how does the program decide which rows belong to which thread?

Throughout this article we will use one small case. The image is 10 rows tall and is divided among 3 threads. Every idea below is checked against that case. Before the explanation of each step, you will be asked to predict one result, so try to answer before reading on.

The first step is to decide how many rows each thread should compute. The program stores this value in an integer called rowsPerThread, and it obtains the value by dividing the image height by the number of threads. Here, height is the vertical size of the image in pixels, and threadCount is the number of threads the user asked for.

Both height and threadCount are integers, so the division is integer division. Integer division drops any fractional part of the result. This matters because it means the division never produces a value that is 'between' whole rows. Whatever is left over has to be handled by a separate rule.

The program loops over the thread numbers, from 0 up to threadCount minus 1. In each pass, it calculates a first row and a last row for that thread. Both values are inclusive, which means both the first row and the last row belong to that thread's work. The loop is where the division of labor becomes concrete.

Applying these formulas to the 10-row, 3-thread case gives the following ranges. Thread 0 starts at row 0 and ends at row 2. Thread 1 starts at row 3 and ends at row 5. Thread 2 is the last thread, so its start row is 3 times 2, which is 6, and its end row is set to height minus 1, which is 9. The figure below shows which thread owns each row.

Notice that row 9 is marked as the one that differs. Threads 0 and 1 each receive exactly rowsPerThread rows, but thread 2 receives four rows. That extra row is produced entirely by the final-thread rule, not by the general formulas.

The same loop can be traced one iteration at a time. The next figure shows how the start and end values change as i moves from 0 to 2. Pay attention to the last iteration, because that is where the exception applies.

The rule for the last thread exists because integer division can leave a remainder. Without the rule, the general formula would assign rows 6 through 8 to thread 2 and leave row 9 belonging to no thread. The program would then skip that row entirely. The exception guarantees that every row from 0 to height minus 1 is covered by exactly one thread.

Once a thread's rows are known, the program creates a Runner object with those two values and stores it in the workers array. The source then sets the new thread's priority to one less than the priority of the thread that is doing the creating, and only after that does it start the thread. The order for each thread is therefore create, set priority, start.

Priority is set during creation, but it does not change which rows a thread receives. The row boundaries are fixed by rowsPerThread and the loop variable i before any thread starts. When debugging a wrong result, you should therefore check the row arithmetic first, because priority only affects how the threads are set up and started.

The source also sets a shared flag named running to true before any thread starts, with a comment warning that the signal must be set before the threads begin. It initializes a counter named threadsCompleted to zero so that the program can later record how many threads have finished. The source excerpt does not show the Runner class itself, so this article treats its constructor only as taking a start row and an end row.