保罗大叔《并发编程难吗？如何应对》：深入理解并发编程必读书籍

需积分: 12 29 浏览量更新于2024-07-17 收藏 6.7MB PDF 举报

《perfbook-1c.2018.12.08a.pdf》是由保罗·麦克肯尼（Paul E. McKenney）编著的一本关于并发编程的权威指南。本书针对并发编程中的挑战和复杂性进行了深入探讨，特别强调了在多线程和分布式系统环境中如何有效地处理并行编程的困难。作者作为Linux Technology Center的专家，以其丰富的经验和深厚的技术背景，为读者提供了实用的解决方案和策略。书中核心知识点包括： 1. **并发编程难度分析**：首先，作者会揭示并发编程的难度，指出在追求高性能时可能会遇到的诸如竞态条件、死锁、数据一致性问题等挑战。他将探讨这些问题为何难以避免，并分析它们对程序性能和稳定性的影响。 2. **锁与同步机制**：并发控制是关键部分，书中深入讲解了锁的原理、使用场景以及各种锁类型（如互斥锁、读写锁、信号量等）的优缺点。同时，还会介绍无锁编程的概念，这是一种旨在减少锁竞争、提高并发性能的技术。 3. **高并发设计原则**：书中提供了一系列设计原则，帮助开发者构建可扩展、易于维护的并发系统。这可能涉及工作负载均衡、任务分解、缓存优化等技术，以确保在高并发环境下系统的稳定性和响应速度。 4. **并行算法与数据结构**：针对特定的并行计算任务，作者可能会讨论并行算法的设计和实现，以及如何利用并行计算框架（如OpenMP、CUDA或MPI）来加速任务执行。 5. **实践案例与示例**：书中包含大量的代码示例和实战案例，读者可以通过这些实例理解理论知识在实际编程中的应用。同时，附带的Git仓库链接允许读者获取和学习源代码，便于进行实践和进一步研究。 6. **开源许可与社区贡献**：非源代码文本和图像部分遵循Creative Commons Attribution-ShareAlike 3.0美国许可证，这意味着读者可以自由地在个人或商业项目中使用文档内容，但必须保持作者的署名并允许修改和衍生作品的传播。综上，《perfbook-1c.2018.12.08a.pdf》是一本对于想要深入了解并发编程及其挑战的专业人士来说不可或缺的参考资料，它不仅提供了理论知识，还提供了实战指导，有助于提升在并行和分布式环境下的编程技能。

4 CHAPTER 1. HOW TO USE THIS BOOK

If your primary focus is scientiﬁc and technical computing, and you prefer a

patternist approach, you might try Mattson et al.’s textbook [

MSM05

]. It covers

Java, C/C++, OpenMP, and MPI. Its patterns are admirably focused ﬁrst on

design, then on implementation.

If your primary focus is scientiﬁc and technical computing, and you are interested

in GPUs, CUDA, and MPI, you might check out Norm Matloﬀ’s “Programming

on Parallel Machines” [

Mat13

]. Of course, the GPU vendors have quite a bit of

additional information [AMD17, Zel11, NVi17a, NVi17b].

If you are interested in POSIX Threads, you might take a look at David R. Buten-

hof’s book [

But97

]. In addition, W. Richard Stevens’s book [

Ste92

] covers UNIX

and POSIX, and Stewart Weiss’s lecture notes [

Wei13

] provide an thorough and

accessible introduction with a good set of examples.

If you are interested in C++11, you might like Anthony Williams’s “C++ Con-

currency in Action: Practical Multithreading” [Wil12].

If you are interested in C++, but in a Windows environment, you might try Herb

Sutter’s “Eﬀective Concurrency” series in Dr. Dobbs Journal [

Sut08

]. This series

does a reasonable job of presenting a commonsense approach to parallelism.

10.

If you want to try out Intel Threading Building Blocks, then perhaps James

Reinders’s book [Rei07] is what you are looking for.

11.

Those interested in learning how various types of multi-processor hardware cache

organizations aﬀect the implementation of kernel internals should take a look at

Curt Schimmel’s classic treatment of this subject [Sch94].

12.

Finally, those using Java might be well-served by Doug Lea’s textbooks [

Lea97

GPB

07].

However, if you are interested in principles of parallel design for low-level software,

especially software written in C, read on!

1.4 Sample Source Code

This book discusses its fair share of source code, and in many cases this source code

may be found in the

CodeSamples

directory of this book’s git tree. For example, on

UNIX systems, you should be able to type the following:

find CodeSamples -name rcu_rcpls.c -print

This command will locate the ﬁle

rcu_rcpls.c

, which is called out in Appendix B.

Other types of systems have well-known ways of locating ﬁles by ﬁlename.

1.5 Whose Book Is This?

As the cover says, the editor is one Paul E. McKenney. However, the editor does

accept contributions via the

perfbook@vger.kernel.org

email list. These contribu-

tions can be in pretty much any form, with popular approaches including text emails,

1.5. WHOSE BOOK IS THIS? 5

Listing 1.1: Creating an Up-To-Date PDF

1 git clone git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/perfbook.git

2 cd perfbook

3 # You may need to install a font here. See item 1 in FAQ.txt.

4 make

5 evince perfbook.pdf & # Two-column version

6 make perfbook-1c.pdf

7 evince perfbook-1c.pdf & # One-column version for e-readers

Listing 1.2: Generating an Updated PDF

1 git remote update

2 git checkout origin/master

3 make

4 evince perfbook.pdf & # Two-column version

5 make perfbook-1c.pdf

6 evince perfbook-1c.pdf & # One-column version for e-readers

patches against the book’s L

X source, and even

git pull

requests. Use whatever

form works best for you.

To create patches or

git pull

requests, you will need the L

X source to the book,

which is at

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/perfbook.

git

. You will of course also need

git

and L

X, which are available as part of most

mainstream Linux distributions. Other packages may be required, depending on the

distribution you use. The required list of packages for a few popular distributions is

listed in the ﬁle FAQ-BUILD.txt in the L

X source to the book.

To create and display a current L

X source tree of this book, use the list of Linux

commands shown in Listing 1.1. In some environments, the

evince

command that

displays

perfbook.pdf

may need to be replaced, for example, with

acroread

. The

git clone

command need only be used the ﬁrst time you create a PDF, subsequently,

you can run the commands shown in Listing 1.2 to pull in any updates and generate an

updated PDF. The commands in Listing 1.2 must be run within the

perfbook

directory

created by the commands shown in Listing 1.1.

PDFs of this book are sporadically posted at

http://kernel.org/pub/linux/

kernel/people/paulmck/perfbook/perfbook.html

and at

http://www.rdrop.

com/users/paulmck/perfbook/.

The actual process of contributing patches and sending

git pull

requests is

similar to that of the Linux kernel, which is documented in the

Documentation/

SubmittingPatches

ﬁle in the Linux source tree. One important requirement is

that each patch (or commit, in the case of a

git pull

request) must contain a valid

Signed-off-by: line, which has the following format:

Signed-off-by: My Name <myname@example.org>

Please see

http://lkml.org/lkml/2007/1/15/219

for an example patch con-

taining a Signed-off-by: line.

It is important to note that the

Signed-off-by:

line has a very speciﬁc meaning,

namely that you are certifying that:

(a)

The contribution was created in whole or in part by me and I have the right to

submit it under the open source license indicated in the ﬁle; or

(b)

The contribution is based upon previous work that, to the best of my knowledge,

is covered under an appropriate open source License and I have the right under

If parallel programming is so hard, why are there any

parallel programs?

Unknown

Chapter 2

Introduction

Parallel programming has earned a reputation as one of the most diﬃcult areas a hacker

can tackle. Papers and textbooks warn of the perils of deadlock, livelock, race conditions,

non-determinism, Amdahl’s-Law limits to scaling, and excessive realtime latencies. And

these perils are quite real; we authors have accumulated uncounted years of experience

dealing with them, and all of the emotional scars, grey hairs, and hair loss that go with

such experiences.

However, new technologies that are diﬃcult to use at introduction invariably become

easier over time. For example, the once-rare ability to drive a car is now commonplace

in many countries. This dramatic change came about for two basic reasons: (1) cars

became cheaper and more readily available, so that more people had the opportunity

to learn to drive, and (2) cars became easier to operate due to automatic transmissions,

automatic chokes, automatic starters, greatly improved reliability, and a host of other

technological improvements.

The same is true of a many other technologies, including computers. It is no

longer necessary to operate a keypunch in order to program. Spreadsheets allow

most non-programmers to get results from their computers that would have required

a team of specialists a few decades ago. Perhaps the most compelling example is

web-surﬁng and content creation, which since the early 2000s has been easily done

by untrained, uneducated people using various now-commonplace social-networking

tools. As recently as 1968, such content creation was a far-out research project [

Eng68

described at the time as “like a UFO landing on the White House lawn”[Gri00].

Therefore, if you wish to argue that parallel programming will remain as diﬃcult as

it is currently perceived by many to be, it is you who bears the burden of proof, keeping

in mind the many centuries of counter-examples in a variety of ﬁelds of endeavor.

2.1 Historic Parallel Programming Diﬃculties

As indicated by its title, this book takes a diﬀerent approach. Rather than complain about

the diﬃculty of parallel programming, it instead examines the reasons why parallel

programming is diﬃcult, and then works to help the reader to overcome these diﬃculties.

As will be seen, these diﬃculties have fallen into several categories, including:

1. The historic high cost and relative rarity of parallel systems.

8 CHAPTER 2. INTRODUCTION

The typical researcher’s and practitioner’s lack of experience with parallel sys-

tems.

3. The paucity of publicly accessible parallel code.

The lack of a widely understood engineering discipline of parallel programming.

The high overhead of communication relative to that of processing, even in tightly

coupled shared-memory computers.

Many of these historic diﬃculties are well on the way to being overcome. First, over

the past few decades, the cost of parallel systems has decreased from many multiples of

that of a house to a fraction of that of a bicycle, courtesy of Moore’s Law. Papers calling

out the advantages of multicore CPUs were published as early as 1996 [

ONH

]. IBM

introduced simultaneous multi-threading into its high-end POWER family in 2000, and

multicore in 2001. Intel introduced hyperthreading into its commodity Pentium line

in November 2000, and both AMD and Intel introduced dual-core CPUs in 2005. Sun

followed with the multicore/multi-threaded Niagara in late 2005. In fact, by 2008, it

was becoming diﬃcult to ﬁnd a single-CPU desktop system, with single-core CPUs

being relegated to netbooks and embedded devices. By 2012, even smartphones were

starting to sport multiple CPUs.

Second, the advent of low-cost and readily available multicore systems means

that the once-rare experience of parallel programming is now available to almost all

researchers and practitioners. In fact, parallel systems are now well within the budget of

students and hobbyists. We can therefore expect greatly increased levels of invention

and innovation surrounding parallel systems, and that increased familiarity will over

time make the once prohibitively expensive ﬁeld of parallel programming much more

friendly and commonplace.

Third, in the 20

century, large systems of highly parallel software were almost

always closely guarded proprietary secrets. In happy contrast, the 21

century has

seen numerous open-source (and thus publicly available) parallel software projects,

including the Linux kernel [

Tor03

], database systems [

Pos08

MS08

], and message-

passing systems [

The08

Uni08a

]. This book will draw primarily from the Linux kernel,

but will provide much material suitable for user-level applications.

Fourth, even though the large-scale parallel

programming projects of the 1980s and

1990s were almost all proprietary projects, these projects have seeded other communities

with a cadre of developers who understand the engineering discipline required to develop

production-quality parallel code. A major purpose of this book is to present this

engineering discipline.

Unfortunately, the ﬁfth diﬃculty, the high cost of communication relative to that

of processing, remains largely in force. Although this diﬃculty has been receiving

increasing attention during the new millennium, according to Stephen Hawking, the

ﬁnite speed of light and the atomic nature of matter is likely to limit progress in this

area [

Gar07

Moo03

]. Fortunately, this diﬃculty has been in force since the late 1980s,

so that the aforementioned engineering discipline has evolved practical and eﬀective

strategies for handling it. In addition, hardware designers are increasingly aware of

these issues, so perhaps future hardware will be more friendly to parallel software as

discussed in Section 3.3.

Quick Quiz 2.1:

Come on now!!! Parallel programming has been known to be

exceedingly hard for many decades. You seem to be hinting that it is not so hard. What

sort of game are you playing?

剩余777页未读，继续阅读

shineliuxing

粉丝: 0
资源: 4

保罗大叔《并发编程难吗？如何应对》：深入理解并发编程必读书籍

perfbook.2019.12.22a.pdf_深入理解并行编程_prefbook_perfbook_

研控控制器系列PMC-TH08A.pdf.pdf

ZJ080NA-08A-20120517.pdf

07-08A答案.doc

OS08A20-rev-1C-Product-Specification-CSP_Version-2-02.pdf

OS08A10-datasheet_Product-Specification-CSP_Version-2-1.pdf

OS08A20-Preliminary-Specification-CSP_Version-1-1_KingHorn.pdf

cudnn-linux-x86-64-8.9.7.29-cuda11-archive.tar.xz

apache-tomcat-8.0.33-windows-x64.zip

jdk-8u211-linux-x64.rpm

最新资源