精通POSIX多线程编程实战指南

需积分: 44 66 浏览量更新于2024-07-27 收藏 1.19MB PDF 举报

在《编程与POSIX线程》（Programming with POSIX Threads）这本经典的多线程编程教程中，作者David Butenhof向读者介绍了在POSIX（Portable Operating System Interface for Unices）环境下进行高效、跨平台的并发编程技术。POSIX是一种广泛应用于Unix-like系统（如Linux、macOS、Solaris等）的标准，定义了一套通用的接口，使得不同的操作系统之间可以共享相似的线程编程模型。本书的核心知识点包括： 1. **POSIX线程库**：POSIX线程库（pthread）是实现多线程功能的基础，它提供了创建、管理线程、同步和通信的函数。理解并掌握这些函数的用法是进行POSIX多线程编程的基础。 2. **线程的基本概念**：包括线程的创建（`pthread_create()`）、销毁（`pthread_exit()`）、同步（如互斥锁、条件变量、信号量）以及线程间的通信（如管道、消息队列）。 3. **线程安全与并发控制**：如何确保数据的一致性和避免竞态条件，通过正确使用锁（mutex）、条件变量（condition variables）和其他同步机制来保护共享资源。 4. **死锁检测与避免**：理解死锁的概念，学习如何通过避免循环等待条件或使用超时策略来预防和解决死锁问题。 5. **线程调度与优先级**：POSIX支持抢占式和非抢占式的线程调度，了解如何设置线程优先级，以控制程序执行的顺序。 6. **线程池与工作队列**：设计高效的线程管理策略，如创建线程池，将任务放入工作队列，以提高程序性能。 7. **跨平台兼容性**：尽管POSIX标准为多线程编程提供了一致性，但不同平台可能有细微的差异，因此理解这些差异并采取相应的处理方法很重要。 8. **错误处理与调试**：学习如何处理线程编程中的异常和错误，以及使用调试工具进行问题排查。这本书不仅适合希望深入了解多线程编程的开发人员，也对系统架构师和操作系统内核开发者具有参考价值。通过阅读和实践，读者能够掌握在POSIX环境中编写健壮、可维护的并发代码的关键技能。无论你是Unix/Linux世界的开发者，还是寻求跨平台编程能力提升者，这本书都是不可或缺的参考资料。

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页未读，继续阅读

mingjingx

粉丝: 0
资源: 1

精通POSIX多线程编程实战指南

Programming with POSIX Threads

多线程编程 UNIX LINUX Programming with POSIX Threads

programming with POSIX threads

POSIX多线程编程入门指南

POSIX多线程编程基础指南

IBM POSIX多线程编程详解

POSIX多线程编程实战指南

C语言中的多线程编程

Linux中的多线程编程指南

学习C语言中的多线程编程

最新资源