Seven Concurrency Models in Seven Weeks: When Threads Unravel (The Pragmatic Programmers)
Paul Butcher
Language: English
Pages: 300
ISBN: 1937785653
Format: PDF / Kindle (mobi) / ePub
Your software needs to leverage multiple cores, handle thousands of users and terabytes of data, and continue working in the face of both hardware and software failure. Concurrency and parallelism are the keys, and Seven Concurrency Models in Seven Weeks equips you for this new world. See how emerging technologies such as actors and functional programming address issues with traditional threads and locks development. Learn how to exploit the parallelism in your computer's GPU and leverage clusters of machines with MapReduce and Stream Processing. And do it all with the confidence that comes from using tools that help you write crystal clear, high-quality code.
This book will show you how to exploit different parallel architectures to improve your code's performance, scalability, and resilience. You'll learn about seven concurrency models: threads and locks, functional programming, separating identity and state, actors, sequential processes, data parallelism, and the lambda architecture.
Learn about the perils of traditional threads and locks programming and how to overcome them through careful design and by working with the standard library. See how actors enable software running on geographically distributed computers to collaborate, handle failure, and create systems that stay up 24/7/365. Understand why shared mutable state is the enemy of robust concurrent code, and see how functional programming together with technologies such as Software Transactional Memory (STM) and automatic parallelism help you tame it.
You'll learn about the untapped potential within every GPU and how GPGPU software can unleash it. You'll see how to use MapReduce to harness massive clusters to solve previously intractable problems, and how, in concert with Stream Processing, big data can be tamed.
With an understanding of the strengths and weaknesses of each of the different models and hardware architectures, you'll be empowered to tackle any problem with confidence.
What You Need:
The example code can be compiled and executed on *nix, OS X, or Windows. Instructions on how to download the supporting build systems are given in each chapter.
Network Convergence: Ethernet Applications and Next Generation Packet Transport Architectures
Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (4th Edition)
Unit Test Frameworks: Tools for High-Quality Software Development
3D Graphics with XNA Game Studio 4.0
JIRA 6.x Administration Cookbook
anything to do with persistence on disk or within a database. Instead it refers to a data structure that always preserves its previous version when it’s modified, which allows code to have a consistent view of the data in the face of modifications. We can see this easily in the REPL: report erratum • discuss Day 1: Atoms and Persistent Data Structures • 89 user=> (def mapv1 {:name "paul" :age 45}) #'user/mapv1 user=> (def mapv2 (assoc mapv1 :sex :male)) #'user/mapv2 user=> mapv1 {:age 45,
processes in more detail. Fault Detection In Linking Processes, on page 119, we used spawn_link() to create a link between two processes so that we could detect when one of them terminated. Links are one of the most important concepts in Elixir programming—let’s investigate them in more depth. Links Propagate Abnormal Termination We can establish a link between two processes at any time with Process.link(). Here’s a small actor that we can use to investigate how links behave:
multiple actors according to a hash function. Create a supervisor that starts multiple cache actors and routes incoming messages to the appropriate cache worker. What action should this supervisor take if one of the cache workers fails? Day 3: Distribution Everything we’ve done so far has been on a single computer, but one of the actor model’s primary benefits compared to the models we’ve seen so far is report erratum • discuss Chapter 5. Actors • 138 that it supports distribution—sending a
would expect, an actor running on one node can send messages to an actor running on another. To demonstrate, let’s spawn an instance of the Counter actor we created earlier (see the code on page 120) on one node: report erratum • discuss Chapter 5. Actors • 144 Joe asks: How Do I Manage My Cluster? A system that allows one machine to execute arbitrary code on another is extremely powerful. Like any powerful tool, it can also be dangerous. In particular, you need to pay careful attention to
answerReady is true? It’s almost as if something switched lines 6 and 7 around underneath our feet. Well, it turns out that it’s entirely possible for something to do exactly that. Several somethings, in fact: • The compiler is allowed to statically optimize your code by reordering things. • The JVM is allowed to dynamically optimize your code by reordering things. • The hardware you’re running on is allowed to optimize performance by reordering things. It goes further than just reordering.
