掌握POSIX线程编程

5星 · 超过95%的资源需积分: 10 60 浏览量更新于2024-07-28 收藏 1.19MB PDF 举报

"Programming with POSIX Threads by David R. Butenhof" 本书是关于使用POSIX线程（也称为pthreads）进行多线程编程的经典指南，由David R. Butenhof撰写，由Addison-Wesley出版。POSIX线程是操作系统接口的一个标准部分，它允许程序员在支持POSIX标准的操作系统上创建和管理多个执行线程，如Unix、Linux、FreeBSD等。通过学习本书，读者可以深入理解如何有效地利用多线程技术提高程序的并发性和性能。在本书中，Butenhof详细介绍了pthreads API，包括线程创建、同步、互斥锁、条件变量、信号量、读写锁等关键概念。他提供了丰富的示例代码，帮助读者理解和应用这些概念到实际的编程任务中。例如，他讨论了如何使用pthread_create函数来创建新的线程，以及如何使用pthread_join来等待线程结束。此外，他还解释了线程的优先级、调度策略以及如何处理线程间的通信和数据共享。线程同步是多线程编程中的核心问题，书中详尽地探讨了各种同步机制。互斥锁（mutexes）用于保护临界区，确保同一时间只有一个线程可以访问特定资源；条件变量（condition variables）允许线程等待特定条件满足后才继续执行；信号量（semaphores）则可用于限制对资源的访问数量。通过这些同步工具，开发者可以避免竞态条件和死锁等并发问题。书中的内容还包括对线程局部存储（TLS）的讨论，这是一种让每个线程拥有自己独立变量的机制，避免了多线程环境下全局变量可能导致的问题。此外，还涵盖了线程安全函数，这些函数在多线程环境中使用时能保证正确性，不引入数据竞争。 Butenhof还涉及了线程生命周期管理，如线程的终止、取消和线程属性的设置。线程取消功能允许在程序运行过程中非阻塞地停止一个线程，这对于实现动态调整和优化程序行为非常有用。线程属性则允许对线程的行为进行细粒度的定制，比如堆栈大小、调度策略等。书中还提到了不同操作系统对pthreads实现的差异，以及如何在多种平台上移植线程代码。这有助于开发者构建跨平台的多线程应用程序。《Programming with POSIX Threads》是一本全面而深入的多线程编程教材，无论对于初学者还是有经验的开发者，都是理解和掌握POSIX线程编程的重要参考资料。通过本书，读者将能够充分利用多线程的优势，设计出高效、可靠的并发应用程序。

As you read this book you'll be introduced to concepts that may seem unfamiliar: mutexes,

condition variables, race conditions, deadlocks, and priority inversions. Threaded programming

may feel daunting and unnatural. But I’ll explain all those concepts as we move through this book,

and once you've been writing multithreaded code for a while you may find yourself noticing

real-world analogies to the concepts. Threads and all this other stuff are formalized and restricted

representations of things you already understand.

If you find yourself thinking that someone shouldn't interrupt you because you have the

conversation mutex locked, you've begun to develop an intuitive understanding of threaded

programming.* You can apply that understanding to help you design better threaded code with less

effort. If something wouldn't make sense in real life, you probably shouldn't try it in a program

either.

* It may also be a good time to take a break and read some healthy escapist fiction for a while.

1.4 About the examples in this book

This book contains a number of examples. All are presented as complete programs, and they

have been built and tested on Digital UNIX 4.0d and Solaris 2.5.

All of these programs do something, but many do not do anything of any particular

importance. The purpose of the examples is to demonstrate thread management and

synchronization techniques, which are mere overhead in most real programs. They would be less

effective at revealing the details if that "overhead" was buried within large programs that "did

something."

Within the book, examples are presented in sections, usually one function at a time. The

source code is separated from the surrounding text by a header and trailer block which include the

file name and, if the example comprises more than one section, a section number and the name of

the function. Each line of the source code has a line number at the left margin. Major functional

blocks of each section are described in specially formatted paragraphs preceding the source code.

These paragraphs are marked by line numbers outside the left margin of the paragraph, denoting

the line numbers in the source listing to which the paragraph refers. Here's an example:

1-2 These lines show the header files included in most of the examples. The <pthread.h> header file

declares constants and prototypes for the Pthreads functions, and the errors.h header file includes

various other headers and some error-checking functions.

sample.c part 1 sampleinfo

I have written these examples to use error checking everywhere. That is, I check for errors on

each function call. As long as you code carefully, this isn't necessary, and some experts

recommend testing only for errors that can result from insufficient resources or other problems

beyond your control. I disagree, unless of course you're the sort of programmer who never makes

a mistake. Checking for errors is not that tedious, and may save you a lot of trouble during

debugging.

You can build and run all of the examples for yourself--the source code is available online at

http://www.aw. com/butenhof/posixcode.html. A Makefile is provided to build all of the examples,

though it requires modifications for various platforms. On Digital UNIX, the examples were built

with CFLAGS=-pthread -stdl -wl. On Solaris, they were built with CFLAGS=-D_REENTRANT

-D_POSIX_C_SOURCE= 199506 - lpthread. Some of the examples require interfaces that may

not be in the Pthreads library on your system, for example, clock_gettime, which is part of the

POSIX.lb realtime standard. The additional realtime library is specified by the RTFLAGS variable,

which is defined as RTFLAGS=-lrt on Digital UNIX, and as RTFLAGS=-lposix4 on Solaris.

On Solaris 2.5 systems, several of the examples require calls to thr_setconcurrency to ensure

proper operation. This function causes Solaris to provide the process with additional concurrency.

In a few cases, the example will not operate at all without this call, and in other cases, the example

would fail to demonstrate some behavior.

1.5 Asynchronous programming, by example

"In one moment I've seen what has hitherto been

Enveloped in absolute mystery,

And without extra charge I will give you at large

A Lesson in Natural History."

--Lewis Carroll, The Hunting of the Snark

This section demonstrates some basic asynchronous programming, using a simple program

that does something vaguely useful, by pretending to be an alarm clock with a command interface

for which you would not consider paying a dime in a store. But then, this book is about threads,

not user interfaces, and the code that I need to show takes up quite enough space already.

The program prompts for input lines in a loop until it receives an error or end of file on stdin.

On each line, the first nonblank token is interpreted as the number of seconds to wait, and the rest

of the line (up to 64 characters) is a message that will be printed when the wait completes. I will

offer two additional versions-- one using multiple processes, and one using multiple threads. We'll

use the three examples to compare the approaches.

1.5.1 The baseline, synchronous version

1 Include the header file errors.h, which includes standard headers like <unistd.h> and

<stdio.h> and defines error reporting macros that are used throughout the examples in this book.

We don't use the error reporting macros in this particular example, but consistency is nice,

sometimes.

9-26 The "baseline" version, alarm.c, is a synchronous alarm program with a single routine, main.

Most of main is a loop, which processes simple commands until fgets returns a NULL (error or

end of file). Each line is "parsed" with sscanf to separate the number of seconds to wait (%d, the

first sequence of digits) from the message string to print (%64[ ^\ n l, the rest of the line, up to 64

characters excluding new line).

alarm.c

The problem with the program alarm.c is that only one alarm request can be active at a time.

If you set an alarm to remind you to do something in 10 minutes (600 seconds), you can't decide

to have it remind you of something else in 5 minutes. The program is doing something

synchronously that you would probably like to be asynchronous.

1.5.2 A version using multiple processes

There are lots of ways to make this program asynchronous; for example, you could run more

than one copy of the program. One way to run multiple copies is to fork a child process for each

command, as shown in alarm_fork.c. The new version is asynchronous--you can enter commands

at any time, and they will be carried out independently. It isn't much more complicated than the

original, which is nice.

27-37 The main difference between alarm.c and alarm_fork.c is that instead of calling sleep directly,

it uses fork to create a new child process, which then calls sleep (and, eventually, printf}

asynchronously, while the parent process continues.

42-46 The primary complication in this version is the need to "reap" any child processes that have

terminated. If the program fails to do this, the system will save them all until the program

terminates. The normal way to reap terminated child processes is to call one of the wait functions.

In this case, we call waitpid, which allows the caller to specify the WNOHANG flag. The function

will immediately reap one child process if any have terminated, or will immediately return with a

process ID (pid) of 0. The parent process continues to reap terminated child processes until there

are no more to reap. When the loop terminates, main loops back to line 13 to read a new

command.

alarm_fork.c

1.5.3 A version using multiple threads

Now, let us try another alarm program, alarm_thread.c. It is much like the fork version in

alarm_fork.c, except that it uses threads instead of child processes to create asynchronous alarms.

Four Pthreads calls are used in this program:

 pthread_create creates a thread running the routine specified in the third argument

(alarm_thread), returning an identifier for the new thread to the variable referenced by

thread.

 pthread_detach allows Pthreads to reclaim the thread's resources as soon as it terminates.

 pthread_exit terminates the calling thread.

 pthread_self returns the calling thread’s identifier.

4-7 The alarm_t structure defines the information stored for each alarm command, the number of

seconds until the alarm is due, and the message string that will be printed by the thread.

alarm_thread.c part 1 definitions

1-8 The alarm thread function is the "alarm thread." That is, each alarm thread is created running

this function, and when the function returns the thread terminates. The function's argument (void

*arg) is the fourth argument that was passed to pthread_create, in this case, a pointer to the control

packet (alarm_t) created for the alarm request that the thread is to satisfy. The thread starts by

"mapping" the void * argument as a pointer to a control packet. The thread detaches itself by

calling pthread_detach, which informs Pthreads that the application does not need to know when

the thread terminates or its termination status.

9-12 The thread sleeps for the number of seconds specified in its control packet, and then prints

the message string. Finally, the thread frees the control packet and returns. When a thread returns

from its initial routine, as it does here, the thread terminates. Normally, Pthreads would hold the

thread's resources so that another thread could later determine that it had exited and retrieve a final

result. Because the thread detached itself, none of that is necessary.

alarm_thread.c part 2 alarm_thread

The main program of alarm thread.c is much the same as the other two variants. It loops,

reading and interpreting command lines as long as it can read from stdin.

12-25 In this variation, main allocates heap storage (alarm_t) for each alarm command. The alarm

time and message are stored in this structure, so each thread can be given the appropriate

information. If the sscanf call fails to "parse" a correct command, the heap storage is freed.

12-26 An alarm thread is created, running function alarm_thread, with the alarm data (alarm_t) as

the thread's argument.

alarm_thread.c part 3 main

1.5.4 Summary

A good way to start thinking about threads is to compare the two asynchronous versions of

the alarm program. First, in the fork version, each alarm has an independent address space, copied

from the main program. That means we can put the seconds and message values into local

variables--once the child has been created (when fork returns), the parent can change the values

without affecting the alarm. In the threaded version, on the other hand, all threads share the same

address space--so we call malloc to create a new structure for each alarm, which is passed to the

new thread. The extra bookkeeping required introduces a little complexity into the threaded

version.

In the version using fork, the main program needs to tell the kernel to free resources used by

each child process it creates, by calling waitpid or some other member of the wait "family." The

alarm_fork.c program, for example, calls waitpid in a loop after each command, to collect all child

processes that have completed. You do not need to wait for a thread unless you need the thread's

return value--in alarm_thread.c, for example, each alarm thread detaches itself (at line 6, part 2) so

that the resources held by the thread will be returned immediately when it terminates.

In the threaded version, the "primary activities" (sleeping and printing the message) must be

coded in a separate routine. In alarm.c and alarm_fork.c, those activities were performed without a

call. In simple cases such as our alarm program, it is often easier to understand the program with

all code in one place, so that might seem like an advantage for alarm_fork. c. In more complicated

programs, though, it is rare that a program's "primary activities" are so simple that they can be

performed in a single routine without resulting in total confusion.

In a real alarm program, you wouldn't want to create a process for each alarm. You might

easily have hundreds of alarms active, and the system probably wouldn't let you create that many

processes. On the other hand, you probably can create hundreds of threads within a process. While

there is no real need to maintain a stack and thread context for each alarm request, it is a perfectly

viable design.

A more sophisticated version of alarm_thread.c might use only two threads: one to read input

from the user, and another to wait for expiration of the next alarm--I'll show that version later,

after we've worked through some more basic concepts. You could do the same thing with two

processes, of course, but it would be more cumbersome. Passing information between two threads

is easy and fast--no shared memory to map, no pipes to read or write, no concerns about whether

you are passing addresses that may not mean the same thing in both processes. Threads share

everything in their address space--any address that's valid in one thread is valid in all threads.

1.6 Benefits of threading

"'O Looking-Glass creatures,' quoth Alice, 'draw near!

'Tis an honour to see me, a favour to hear:

'Tis a privilege high to have dinner and tea

Along with the Red Queen, the White Queen, and me!'"

--Lewis Carroll, Through the Looking-Glass

Some advantages of the multithreaded programming model follow:

1. Exploitation of program parallelism on multiprocessor hardware. Parallelism is the only

benefit that requires special hardware. The others can help most programs without special

hardware.

2. More efficient exploitation of a program's natural concurrency, by allowing the program

to perform computations while waiting for slow I/O operations to complete.

3. A modular programming model that clearly expresses relationships between

independent "events" within the program.

These advantages are detailed in the following sections.

1.6.1 Parallelism

On a multiprocessor system, threading allows a process to perform more than one

independent computation at the same time. A computation-intensive threaded application running

on two processors may achieve nearly twice the performance of a traditional single-threaded

version. "Nearly twice" takes into account the fact that you'll always have some overhead due to

creating the extra thread(s) and performing synchronization. This effect is often referred to as

"scaling." A two-processor system may perform 1.95 times as fast as a single processor, a

three-processor system 2.9 times as fast, a four-processor system 3.8 times as fast, and so forth.

Scaling almost always falls off as the number of processors increases because there's more chance

of lock and memory collisions, which cost time.

Speedup

+−

)1(

FIGURE 1.1 Amdahl's law

Scaling can be predicted by "Amdahl's law," which is shown in Figure 1.1. In the equation, p

represents the ratio of "parallelizable code" over "total execution time," and n represents the

number of processors the code can use. The total elapsed time for a parallel job is the sum of the

elapsed time for the nonparallelizable work (1 - p) and the elapsed time for each processor

executing the parallelizable work (p/n).

Amdahl’s law is a simple relationship showing how parallelism is limited by the amount of

剩余201页未读，继续阅读

mouse20092010

粉丝: 0
资源: 1

掌握POSIX线程编程

Programming with POSIX Threads

Programming with POSIX Threads 英文版+ 中文版+源码

Programming with POSIX Threads(多线程编程PDF版本）

Programming With POSIX Threads

programming with POSIX threads

Programming with POSIX Threads 源码

Programming With POSIX Threads 源码

Programming with POSIX Threads by David

Programming with Posix Threads.pdf

Addison Wesley- Programming with Posix Threads

最新资源