Programming Python (27 page)

^[
13
]
At least in the current Python implementation, calling
os.fork
in a Python script actually copies
the Python interpreter process (if you look at your process list,
you’ll see two Python entries after a fork). But since the Python
interpreter records everything about your running script, it’s OK to
think of
fork
as copying your
program directly. It really will if Python scripts are ever compiled
to binary machine code.

Let’s start off by
experimenting with a script that demonstrates the main
thread interfaces. The script in
Example 5-5
spawns threads until you
reply with a
q
at the console; it’s similar in
spirit to (and a bit simpler than) the script in
Example 5-1
, but it goes parallel
with threads instead of process forks.

"spawn threads until you type 'q'"
import _thread
def child(tid):
print('Hello from thread', tid)
def parent():
i = 0
while True:
i += 1
_thread.start_new_thread(child, (i,))
if input() == 'q': break
parent()

This script really contains only two thread-specific lines: the
import of the
_thread
module and
the thread creation call. To start a thread, we simply call
the
_thread.start_new_thread
function, no matter
what platform we’re programming on.
^[
14
]
This call takes a function (or other callable) object
and an arguments tuple and starts a new thread to execute a call to
the passed function with the passed arguments. It’s almost like
Python’s
function(*args)
call
syntax, and similarly accepts an optional keyword arguments
dictionary, too, but in this case the function call begins running in
parallel with the rest of the program.

Operationally speaking, the
_thread.start_new_thread
call itself returns
immediately with no useful value, and the thread it spawns silently
exits when the function being run returns (the return value of the
threaded function call is simply ignored). Moreover, if a function run
in a thread raises an uncaught exception, a stack trace is printed and
the thread exits, but the rest of the program continues. With the
_thread
module, the entire program
exits silently on most platforms when the main thread does (though as
we’ll see later, the
threading
module may require special handling if child threads are still
running).

In practice, though, it’s almost trivial to use threads in a
Python script. Let’s run this program to launch a few threads; we can
run it on both Unix-like platforms and Windows this time, because
threads are more portable than process forks—here it is spawning
threads on Windows:

C:\...\PP4E\System\Threads>
python thread1.py
Hello from thread 1
Hello from thread 2
Hello from thread 3
Hello from thread 4
q

Each message here is printed from a new thread, which exits
almost as soon as it
is started.

Although the
preceding script runs a simple function
, any
callable object
may be run in the thread, because all
threads live in the same process. For instance, a thread can also run
a lambda function or bound method of an object (the following code is
part of file
thread-alts.py
in
the book examples package):

import _thread                                       # all 3 print 4294967296
def action(i):                                       # function run in threads
print(i ** 32)
class Power:
def __init__(self, i):
self.i = i
def action(self):                                # bound method run in threads
print(self.i ** 32)
_thread.start_new_thread(action, (2,))               # simple function
_thread.start_new_thread((lambda: action(2)), ())    # lambda function to defer
obj = Power(2)
_thread.start_new_thread(obj.action, ())             # bound method object

As we’ll see in larger examples later in this book,
bound methods
are especially useful in this
role—because they remember both the method function and instance
object, they also give access to state information and class methods
for use within and during the thread.

More fundamentally, because threads all run in the same process,
bound methods run by threads reference the original in-process
instance object, not a copy of it. Hence, any changes to its state
made in a thread will be visible to all threads automatically.
Moreover, since bound methods of a class instance pass for callables
interchangeably with simple functions, using them in threads this way
just works. And as we’ll see later, the fact that they are normal
objects also allows them to be stored freely on shared queues.

To really
understand the power of threads running in parallel,
though, we have to do something more long-lived in our threads, just
as we did earlier for processes. Let’s mutate the
fork-count
program of the prior section to
use threads. The script in
Example 5-6
starts 5 copies of its
counter
function running in
parallel threads.

"""
thread basics: start 5 copies of a function running in parallel;
uses time.sleep so that the main thread doesn't die too early--
this kills all other threads on some platforms; stdout is shared:
thread outputs may be intermixed in this version arbitrarily.
"""
import _thread as thread, time
def counter(myId, count):                        # function run in threads
for i in range(count):
time.sleep(1)                            # simulate real work
print('[%s] => %s' % (myId, i))
for i in range(5):                               # spawn 5 threads
thread.start_new_thread(counter, (i, 5))     # each thread loops 5 times
time.sleep(6)
print('Main thread exiting.')                    # don't exit too early

Each parallel copy of the
counter
function simply counts from zero up
to four here and prints a message to standard output for each
count.

Notice how this script sleeps for 6 seconds at the end. On
Windows and Linux machines this has been tested on, the main thread
shouldn’t exit while any spawned threads are running if it cares about
their work; if it does exit, all spawned threads are immediately
terminated. This differs from processes, where spawned children live
on when parents exit. Without the sleep here, the spawned threads
would die almost immediately after they are started.

This may seem ad hoc, but it isn’t required on all platforms,
and programs are usually structured such that the main thread
naturally lives as long as the threads it starts. For instance, a user
interface may start an FTP download running in a thread, but the
download lives a much shorter life than the user interface itself.
Later in this section, we’ll also see different ways to avoid this
sleep using global locks and flags that let threads signal their
completion.

Moreover, we’ll later find that the
threading
module both provides a
join
method that lets us wait for spawned
threads to finish explicitly, and refuses to allow a program to exit
at all if any of its normal threads are still running (which may be
useful in this case, but can require extra work to shut down in
others). The
multiprocessing
module
we’ll meet later in this chapter also allows spawned children to
outlive their parents, though this is largely an artifact of its
process-based model.

Now, when
Example 5-6
is
run on Windows 7 under Python 3.1, here is the output I get:

C:\...\PP4E\System\Threads>
python thread-count.py
[1] => 0
[1] => 0
[0] => 0
[1] => 0
[0] => 0
[2] => 0
[3] => 0
[3] => 0
[1] => 1
[3] => 1
[3] => 1
[0] => 1[2] => 1
[3] => 1
[0] => 1[2] => 1
[4] => 1
[1] => 2
[3] => 2[4] => 2
[3] => 2[4] => 2
[0] => 2
[3] => 2[4] => 2
[0] => 2
[2] => 2
[3] => 2[4] => 2
[0] => 2
[2] => 2
...more output omitted...
Main thread exiting.

If this looks odd, it’s because it should. In fact, this
demonstrates probably the most unusual aspect of threads. What’s
happening here is that the output of the 5 threads run in parallel is
intermixed—because all the threaded function calls run in the same
process, they all share the same standard output stream (in Python
terms, there is just one
sys.stdout
file between them, which is where printed text is sent). The net
effect is that their output can be combined and confused arbitrarily.
In fact, this script’s output can differ on each run. This jumbling of
output grew even more pronounced in Python 3, presumably due to its
new file output implementation.

More fundamentally, when multiple threads can access a shared
resource like this, their access must be synchronized to avoid overlap
in time—as explained in the next
section.

One of the nice things
about threads is that they automatically come with a
cross-task communications mechanism: objects and namespaces in a
process that span the life of threads are shared by all spawned
threads. For instance, because every thread runs in the same process,
if one Python thread changes a global scope variable, the change can
be seen by every other thread in the process, main or child.
Similarly, threads can share and change mutable objects in the
process’s memory as long as they hold a reference to them (e.g.,
passed-in arguments). This serves as a simple way for a program’s
threads to pass information—exit flags, result objects, event
indicators, and so on—back and forth to each other.

The downside to this scheme is that our threads must sometimes
be careful to avoid changing global objects and names at the same
time. If two threads may change a shared object at once, it’s not
impossible that one of the two changes will be lost (or worse, will
silently corrupt the state of the shared object completely): one
thread may step on the work done so far by another whose operations
are still in progress. The extent to which this becomes an issue
varies per application, and sometimes it isn’t an issue at all.

But even things that aren’t obviously at risk may be at risk.
Files and streams, for example, are shared by all threads in a
program; if multiple threads write to one stream at the same time, the
stream might wind up with interleaved, garbled data.
Example 5-6
of the prior section was
a simple demonstration of this phenomenon in action, but it’s
indicative of the sorts of clashes in time that can occur when our
programs go parallel. Even simple changes can go awry if they might
happen concurrently. To be robust, threaded programs need to control
access to shared global items like these so that only one thread uses
them at once.

Luckily, Python’s
_thread
module comes with its own easy-to-use tools for synchronizing access
to objects shared among threads. These tools are based on the concept
of a
lock
—to change a shared object, threads
acquire
a lock, make their changes, and then
release
the lock for other threads to grab.
Python ensures that only one thread can hold a lock at any point in
time; if others request it while it’s held, they are blocked until the
lock becomes available. Lock objects are allocated and processed with
simple and portable calls in the
_thread
module that are automatically mapped
to thread locking mechanisms on the underlying platform.

For instance, in
Example 5-7
, a lock object created
by
_thread.allocate_lock
is acquired and
released by each thread around the
print
call that writes to the shared
standard output stream.

"""
synchronize access to stdout: because it is shared global,
thread outputs may be intermixed if not synchronized
"""
import _thread as thread, time
def counter(myId, count):                        # function run in threads
for i in range(count):
time.sleep(1)                            # simulate real work
mutex.acquire()
print('[%s] => %s' % (myId, i))          # print isn't interrupted now
mutex.release()
mutex = thread.allocate_lock()                   # make a global lock object
for i in range(5):                               # spawn 5 threads
thread.start_new_thread(counter, (i, 5))     # each thread loops 5 times
time.sleep(6)
print('Main thread exiting.')                    # don't exit too early

Really, this script simply augments
Example 5-6
to synchronize prints
with a thread lock. The net effect of the additional lock calls in
this script is that no two threads will ever execute a
print
call at the same point in time; the
lock ensures mutually exclusive access to the
stdout
stream. Hence, the output of this
script is similar to that of the original version, except that
standard output text is never mangled by overlapping prints:

C:\...\PP4E\System\Threads>
thread-count-mutex.py
[0] => 0
[1] => 0
[3] => 0
[2] => 0
[4] => 0
[0] => 1
[1] => 1
[3] => 1
[2] => 1
[4] => 1
[0] => 2
[1] => 2
[3] => 2
[4] => 2
[2] => 2
[0] => 3
[1] => 3
[3] => 3
[4] => 3
[2] => 3
[0] => 4
[1] => 4
[3] => 4
[4] => 4
[2] => 4
Main thread exiting.

Though somewhat platform-specific, the order in which the
threads check in with their prints may still be arbitrary from run to
run because they execute in parallel (getting work done in parallel is
the whole point of threads, after all); but they no longer collide in
time while printing their text. We’ll see other cases where the lock
idiom comes in to play later in this chapter—it’s a core component of
the multithreading
model.