Threads

16 June 2001 WORK IN PROGRESS!

he logical extension to multitasking programs is to split a program into a number of parts (threads) and run each of these on the multitasking system (multi-threading). Multi-threading can be likened to splitting sequential tasks, into a number of interrelated tasks. For example, let's say that you have to cook a meal with the following recipe:

1. Put potatoes on to boil.
2. Put pie in the microwave, on HIGH for 10 minutes.
3. Wait for potatoes to become soft.
4. Take potatoes out of pan, and place on the plates.
5. Wait for pie to complete.
6. Take pie out of microwave and place on the plates.
7. Put carrots in pan, and boil.
8. Wait for carrots to become soft.
9. Take carrots out of pan, and place on the plates.

The problem with this recipe is that someone could be waiting at step 4 to complete, while they could be checking the pie to see if it has complete. An improved method would use independent subtask, which were interrelated. In this case the pie and the potatoes are not interrelated, but the potatoes and the carrots are (assuming that we only have one pan). Figure 3.9 shows a possible schedule using subtasks (or threads of the main task), where we now have six main threads. Each of the threads can run independently, but some cannot run to until they have received something from another thread. For example it is not possible for the 'Put potatoes on plate' thread to start until it has received the potatoes from the 'Boil potatoes' thread.

A threads-based approach allows us to create specialized task, which have a small defini-tive goal. It is much easier to test a small program which has a definitive task, rather than to test a large and complex piece of software. It is also easier to upgrade a thread, without af-fecting the overall operation of the complete program.