掌握并行开发的艺术：解锁多线程效率

4星 · 超过85%的资源需积分: 3 17 浏览量更新于2024-07-28 收藏 14.34MB PDF 举报

《并行开发的艺术》是一本由Clay Breshears编写的专著，旨在深入探讨并行编程和并发技术在现代IT领域的核心艺术。这本书于2009年首次出版，版权全属Clay Breshears所有，由O'Reilly Media公司发行，适用于教育、商业和销售推广用途，电子版也在O'Reilly Safari在线平台上提供。作者以富有经验的视角，引领读者穿越并发编程的迷宫，理解并掌握并行开发的关键概念、设计原则和实践策略。书中涵盖的主题包括但不限于： 1. **并发基础**：介绍并发和并行的区别，解释线程、进程、任务和工作线程的概念，以及它们在多核处理器时代的重要性。 2. **并发模型**：探讨各种并发模型，如消息传递、共享内存、无锁编程和数据并行等，以及它们适用的场景和优缺点。 3. **并发控制**：讲解死锁、活锁、饥饿问题等并发控制挑战，以及如何通过同步原语（如互斥锁、信号量、条件变量）来管理和协调并发操作。 4. **并发编程语言**：对比不同的编程语言（如Java、C++、Python和Go等）在并发支持上的特性，以及如何选择最适合的工具和技术栈。 5. **分布式系统**：讨论分布式计算和云计算环境下的并行开发，包括负载均衡、网络通信和分布式数据结构。 6. **性能优化与可扩展性**：提供实用的性能调优技巧，如避免全局状态、使用惰性计算和缓存优化，以及如何设计可扩展的并行架构。 7. **实战案例与最佳实践**：书中包含多个实际项目案例，展示如何应用并行开发技术解决复杂问题，以及业界公认的优秀设计模式和最佳实践。 8. **调试与故障处理**：介绍调试并行程序的技巧，如何识别和处理常见的并发问题，确保系统的稳定性和可靠性。《并行开发的艺术》不仅仅是一本技术手册，它还提供了深入理解和掌握并发世界所需的艺术视角和实践经验，适合软件工程师、系统架构师和高级开发者阅读，无论是在构建单机高性能应用，还是设计分布式系统时，都能从中获益匪浅。

“[A]nd in this precious phial is the power to think twice

as fast, move twice as quickly, do twice as much work in

a given time as you could otherwise do.”

—H. G. Wells, “The New Accelerator” (1901)

WITH THIS BOOK I WANT TO PEEL BACK THE VEILS OF MYSTERY , MISERY, AND misunderstanding

that surround concurrent programming. I want to pass along to you some of the tricks, secrets,

and skills that I’ve learned over my last two decades of concurrent and parallel programming

experience.

I will demonstrate these tricks, secrets, and skills—and the art of concurrent programming—

by developing and implementing concurrent algorithms from serial code. I will explain the

thought processes I went through for each example in order to give you insight into how

concurrent code can be developed. I will be using threads as the model of concurrency in a

shared-memory environment for all algorithms devised and implemented. Since this isn’t a

book on one specific threading library, I’ve used several of the common libraries throughout

and included some hints on how implementations might differ, in case your preferred method

wasn’t used.

Like any programming skill, there is a level of mechanics involved in being ready and able to

attempt concurrent or multithreaded programming. You can learn these things (such as syntax,

methods for mutual exclusion, and sharing data) through study and practice. There is also a

necessary component of logical thinking skills and intuition needed to tackle or avoid even

simple concurrent programming problems successfully. Being able to apply that logical

thinking and having some intuition, or being able to think about threads executing in parallel

with each other, is the art of concurrent and multithreaded programming. You can learn some

of this through demonstration by experts, but that only works if the innate ability is already

there and you can apply the lessons learned to other situations. Since you’ve picked up this

volume, I’m sure that you, my fine reader, already possess such innate skills. This book will

help you shape and aim those skills at concurrent and multithreaded programming.

Some Questions You May Have

Before we get started, there are some questions you may have thought up while reading those

first few paragraphs or even when you saw this book on the shelves before picking it up. Let’s

take a look at some of those questions now.

What Is a Thread Monkey?

thread monkey

is a programmer capable of designing multithreaded, concurrent, and parallel

software, as well as grinding out correct and efficient code to implement those designs. Much

like a “grease monkey” is someone who can work magic on automobiles, a thread monkey is

2 C HA PT ER 1 : W AN T TO G O FA ST ER ? RA IS E YO UR H AN DS I F YO U WA NT T O GO F AS TE R!

a wiz at concurrent programming. Thread monkey is a title of prestige, unlike the often

derogatory connotations associated with “code monkey.”

Parallelism and Concurrency: What’s the Difference?

The terms “parallel” and “concurrent” have been tossed around with increasing frequency

since the release of general-purpose multicore processors. Even prior to that, there has been

some confusion about these terms in other areas of computation. What is the difference, or

there a difference, since use of these terms seems to be almost interchangeable?

A system is said to be

concurrent

if it can support two or more actions

in progress

at the same

time. A system is said to be

parallel

if it can support two or more actions executing

simultaneously. The key concept and difference between these definitions is the phrase “in

progress.”

A concurrent application will have two or more threads in progress at some time. This can

mean that the application has two threads that are being swapped in and out by the operating

system on a single core processor. These threads will be “in progress”—each in the midst of its

execution—at the same time. In parallel execution, there must be multiple cores available

within the computation platform. In that case, the two or more threads could each be assigned

a separate core and would be running simultaneously.

I hope you’ve already deduced that “parallel” is a subset of “concurrent.” That is, you can write

a concurrent application that uses multiple threads or processes, but if you don’t have multiple

cores for execution, you won’t be able to run your code in parallel. Thus,

concurrent

programming

and

concurrency

encompass all programming and execution activities that

involve multiple streams of execution being implemented in order to solve a single problem.

For about the last 20 years, the term

parallel programming

has been synonymous with

message-passing or distributed-memory programming. With multiple compute nodes in a

cluster or connected via some network, each node with one or more processors, you had a

parallel platform. There is a specific programming methodology required to write applications

that divide up the work and share data. The programming of applications utilizing threads has

been thought of as concurrent programming, since threads are part of a shared-memory

programming model that fits nicely into a single core system able to access the memory within

the platform.

I will be striving to use the terms “parallel” and “concurrent” correctly throughout this book.

This means that

concurrent programming

and

design of concurrent algorithms

will assume

that the resulting code is able to run on a single core or multiple cores without any drastic

changes. Even though the implementation model will be threads, I will talk about the parallel

execution of concurrent codes, since I assume that we all have multicore processors available

on which to execute those multiple threads. Also, I’ll use the term “parallelization” as the

process of translating applications from serial to concurrent (and the term “concurrentization”

doesn’t roll off the tongue quite as nicely).

S om e Qu es ti on s Yo u Ma y Ha ve 3

Why Do I Need to Know This? What’s in It for Me?

I’m tempted to be a tad flippant and tell you that there’s no way to avoid this topic; multicore

processors are here now and here to stay, and if you want to remain a vital and employable

programmer, you have no choice but to learn and master this material. Of course, I’d be waving

my hands around manically for emphasis and trying to put you into a frightened state of mind.

While all that is true to some degree, a kinder and gentler approach is more likely to gain your

trust and get you on board with the concurrent programming revolution.

Whether you’re a faceless corporate drone for a large software conglomerate, writing code for

a small in-house programming shop, doing open source development, or just dabbling with

writing software as a hobby, you are going to be touched by multicore processors to one degree

or another. In the past, to get a burst of increased performance out of your applications, you

simply needed to wait for the next generation of processor that had a faster clock speed than

the previous model. A colleague of mine once postulated that you could take nine months off

to play the drums or surf, come back after the new chips had been released, run some

benchmarks, and declare success. In his seminal (and by now, legendary) article, “The Free

Lunch Is Over: A Fundamental Turn Toward Concurrency in Software” (

Dr. Dobb’s Journal

March 2005), Herb Sutter explains that this situation is no longer viable. Programmers will

need to start writing concurrent code in order to take full advantage of multicore processors

and achieve future performance improvements.

What kinds of performance improvements can you expect with concurrent programming on

multicore processors? As an upper bound, you could expect applications to run in half the time

using two cores, one quarter of the time running on four cores, one eighth of the time running

on eight cores, and so on. This sounds much better than the 20–30% decrease in runtime when

using a new, faster processor. Unfortunately, it takes some work to get code whipped into shape

and capable of taking advantage of multiple cores. Plus, in general, very few codes will be able

to achieve these upper bound levels of increased performance. In fact, as the number of cores

increases, you may find that the relative performance actually decreases. However, if you can

write good concurrent and multithreaded applications, you will be able to achieve respectable

performance increases (or be able to explain why you can’t). Better yet, if you can develop

your concurrent algorithms in such a way that the same relative performance increases seen

on two and four cores remains when executing on 8, 16, or more cores, you may be able to

devote some time to your drumming and surfing. A major focus of this book will be pointing

out when and how to develop such

scalable

algorithms.

Isn’t Concurrent Programming Hard?

Concurrent programming is no walk in the park, that’s for sure. However, I don’t think it is as

scary or as difficult as others may have led you to think. If approached in a logical and informed

fashion, learning and practicing concurrent programming is no more difficult than learning

another programming language.

4 C HA PT ER 1 : W AN T TO G O FA ST ER ? RA IS E YO UR H AN DS I F YO U WA NT T O GO F AS TE R!

剩余303页未读，继续阅读

gflytu

粉丝: 190
资源: 76

掌握并行开发的艺术：解锁多线程效率

掌握多核并行开发实战艺术：《并行开发的艺术》详解

并行开发实战：解锁并发编程艺术

并行开发实战：多核处理器的性能优化

并发的艺术 英文版(开发并行代码算法程序员必备手册 ) The Art of Concurrency: A Thread Monkey's Guide to Writing Parallel Applications

Android 开发艺术探索源码

探索 Java 8 Stream 中的 `Collectors.groupingByConcurrent()`：并行处理的艺术

并行编程艺术：Clay Breshears的并发指南

零MQ指南：连接世界并行编程的艺术

Qt框架详解：并行动画与GUI开发实践

多处理器编程艺术：解锁数据结构并行实践

最新资源

并发的艺术英文版(开发并行代码算法程序员必备手册 ) The Art of Concurrency: A Thread Monkey's Guide to Writing Parallel Applications