Wesley J. Chun explores the different ways you can achieve more parallelism in your code, including the difference between processes and threads, some multithreaded programming features found in Python, and some examples of how to use the threading and Queue modules to accomplish multithreaded programming with Python.



> With Python you can start a thread, but you can’t stop it.

> Sorry. You’ll have to wait until it reaches the end of execution. So, just the same as [comp.lang.python], then?

—Cliff Wells, Steve Holden (and Timothy Delaney), February 2002

In this chapter...

Introduction/Motivation

Threads and Processes

Threads and Python

The thread Module

Module The threading Module

Module Comparing Single vs. Multithreaded Execution

Multithreading in Practice

Producer-Consumer Problem and the Queue/ queue Module

Module Alternative Considerations to Threads

Related Modules

In this section, we will explore the different ways by which you can achieve more parallelism in your code. We will begin by differentiating between processes and threads in the first few of sections of this chapter. We will then introduce the notion of multithreaded programming and present some multithreaded programming features found in Python. (Those of you already familiar with multithreaded programming can skip directly to Section 4.3.5.) The final sections of this chapter present some examples of how to use the threading and Queue modules to accomplish multithreaded programming with Python.

4.1. Introduction/Motivation

Before the advent of multithreaded (MT) programming, the execution of computer programs consisted of a single sequence of steps that were executed in synchronous order by the host’s CPU. This style of execution was the norm whether the task itself required the sequential ordering of steps or if the entire program was actually an aggregation of multiple subtasks. What if these subtasks were independent, having no causal relationship (meaning that results of subtasks do not affect other subtask outcomes)? Is it not logical, then, to want to run these independent tasks all at the same time? Such parallel processing could significantly improve the performance of the overall task. This is what MT programming is all about.

MT programming is ideal for programming tasks that are asynchronous in nature, require multiple concurrent activities, and where the processing of each activity might be nondeterministic, that is, random and unpredictable. Such programming tasks can be organized or partitioned into multiple streams of execution wherein each has a specific task to accomplish. Depending on the application, these subtasks might calculate intermediate results that could be merged into a final piece of output.

While CPU-bound tasks might be fairly straightforward to divide into subtasks and executed sequentially or in a multithreaded manner, the task of managing a single-threaded process with multiple external sources of input is not as trivial. To achieve such a programming task without multithreading, a sequential program must use one or more timers and implement a multiplexing scheme.

A sequential program will need to sample each I/O terminal channel to check for user input; however, it is important that the program does not block when reading the I/O terminal channel, because the arrival of user input is nondeterministic, and blocking would prevent processing of other I/O channels. The sequential program must use non-blocked I/O or blocked I/O with a timer (so that blocking is only temporary).

Because the sequential program is a single thread of execution, it must juggle the multiple tasks that it needs to perform, making sure that it does not spend too much time on any one task, and it must ensure that user response time is appropriately distributed. The use of a sequential program for this type of task often results in a complicated flow of control that is difficult to understand and maintain.

Using an MT program with a shared data structure such as a Queue (a multithreaded queue data structure, discussed later in this chapter), this programming task can be organized with a few threads that have specific functions to perform:

UserRequestThread: Responsible for reading client input, perhaps from an I/O channel. A number of threads would be created by the program, one for each current client, with requests being entered into the queue.

Responsible for reading client input, perhaps from an I/O channel. A number of threads would be created by the program, one for each current client, with requests being entered into the queue. RequestProcessor: A thread that is responsible for retrieving requests from the queue and processing them, providing output for yet a third thread.

A thread that is responsible for retrieving requests from the queue and processing them, providing output for yet a third thread. ReplyThread: Responsible for taking output destined for the user and either sending it back (if in a networked application) or writing data to the local file system or database.