Thread Creation and Management

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 central question is simple to state but easy to get wrong: how does the program decide which rows belong to which thread?

Keep one small case in mind throughout this article. The image is 10 rows tall, and it is divided among 3 threads. Every idea below is checked against this case.

Each thread receives an inclusive band of rows. Inclusive means both the start row and the end row belong to that thread's work. Before looking at the formulas, look at the result the program is aiming for. With 10 rows and 3 threads, the rows should be split into three contiguous blocks that together cover every row from 0 to 9 exactly once.

The first step is to decide how many rows each thread should compute. The program stores this in an integer called rowsPerThread. Here, height is the vertical size of the image in pixels, and threadCount is the number of threads the user asked for. Both values are integers, so the division is integer division, and any fractional part is dropped.

For our example, 10 divided by 3 gives 3 rows per thread, with 1 row left over. Multiplying 3 by 3 threads accounts for only 9 rows. The per-thread value alone cannot cover the whole image, so the assignment needs a rule for the last thread.

For every thread except the last, the program uses two formulas. The start row is rowsPerThread times i, and the end row is rowsPerThread times (i + 1) minus 1, where i is the thread number. These formulas give each thread a block of exactly rowsPerThread rows.

Each thread's range is inclusive at both ends, so the ranges fit together with no gap and no overlap. Thread 0 ends at row 2 and thread 1 starts at row 3. Thread 1 ends at row 5 and thread 2 starts at row 6. The only range that changes its shape is the last one, which stretches to row 9 to absorb the leftover row.

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

Before the loop starts, the source sets a shared flag named running to true, with a comment warning that the signal must be set before the threads begin. It also initializes a counter, threadsCompleted, to zero so 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.

When the result does not match expectations, the bug almost always traces back to a small set of steps in the assignment calculation. The list below names the most common ones, each tied to the 10-row, 3-thread case.