SlideShare a Scribd company logo
Distributed Computing Seminar Lecture 1: Introduction to Distributed  Computing & Systems Background Christophe Bisciglia, Aaron Kimball, & Sierra Michels-Slettvet Summer 2007 Except where otherwise noted, the contents of this presentation are © Copyright 2007 University of Washington and are licensed under the Creative Commons Attribution 2.5 License.
Course Overview 5 lectures 1 Introduction 2 Technical Side: MapReduce & GFS 2 Theoretical: Algorithms for distributed computing Readings + Questions nightly Readings: http://code.google.com/edu/content/submissions/mapreduce-minilecture/listing.html Questions: http://code.google.com/edu/content/submissions/mapreduce-minilecture/MapReduceMiniSeriesReadingQuestions.doc
Outline Introduction to Distributed Computing Parallel vs. Distributed Computing History of Distributed Computing Parallelization and Synchronization Networking Basics
Computer Speedup Moore’s Law: “ The density of transistors on a chip doubles every 18 months, for the same cost”  (1965) Image: Tom’s Hardware and not subject to the Creative Commons license applicable to the rest of this work.  Image: Tom’s Hardware
Scope of problems What can you do with 1 computer? What can you do with 100 computers? What can you do with an entire data center?
Distributed problems Rendering multiple frames of high-quality animation Image: DreamWorks Animation and not subject to the Creative Commons license applicable to the rest of this work.
Distributed problems Simulating several hundred or thousand characters  Happy Feet  © Kingdom Feature Productions; Lord of the Rings  © New Line Cinema, neither image is subject to the Creative Commons license applicable to the rest of the work.
Distributed problems Indexing the web (Google) Simulating an Internet-sized network for networking experiments (PlanetLab) Speeding up content delivery (Akamai) What is the key attribute that all these examples have in common?
Parallel vs. Distributed Parallel computing can mean: Vector processing of data Multiple CPUs in a single computer Distributed computing is multiple CPUs across many computers over the network
A Brief History… 1975-85 Parallel computing was favored in the early years Primarily vector-based at first Gradually more thread-based parallelism was introduced Image:  Computer Pictures Database and Cray Research Corp and is not subject to the Creative Commons license applicable to the rest of this work.
“ Massively parallel architectures” start rising in prominence Message Passing Interface (MPI) and other libraries developed Bandwidth was a big problem A Brief History… 1985-95
A Brief History… 1995-Today Cluster/grid architecture increasingly dominant Special node machines eschewed in favor of COTS technologies Web-wide cluster software Companies like Google take this to the extreme
Parallelization & Synchronization
Parallelization Idea Parallelization is “easy” if processing can be cleanly split into n units:
Parallelization Idea (2) In a parallel computation, we would like to have as many threads as we have processors. e.g., a four-processor computer would be able to run four threads at the same time.
Parallelization Idea (3)
Parallelization Idea (4)
Parallelization Pitfalls But this model is too simple!  How do we assign work units to worker threads? What if we have more work units than threads? How do we aggregate the results at the end? How do we know all the workers have finished? What if the work cannot be divided into completely separate tasks? What is the common theme of all of these problems?
Parallelization Pitfalls (2) Each of these problems represents a point at which multiple threads must communicate with one another, or access a shared resource. Golden rule: Any memory that can be used by multiple threads must have an associated  synchronization system !
What is Wrong With This? Thread 1: void foo() { x++; y = x; } Thread 2: void bar() { y++; x+=3; } If the initial state is y = 0, x = 6, what happens after these threads finish running?
Multithreaded = Unpredictability When we run a multithreaded program, we don’t know what order threads run in, nor do we know when they will interrupt one another. Thread 1: void foo() { eax = mem[x]; inc eax; mem[x] = eax; ebx = mem[x]; mem[y] = ebx; } Thread 2: void bar() { eax = mem[y]; inc eax; mem[y] = eax; eax = mem[x]; add eax, 3; mem[x] = eax; } Many things that look like “one step” operations actually take several steps under the hood:
Multithreaded = Unpredictability This applies to more than just integers: Pulling work units from a queue Reporting work back to master unit Telling another thread that it can begin the “next phase” of processing …  All require synchronization!
Synchronization Primitives A  synchronization primitive  is a special shared variable that guarantees that it can only be accessed  atomically .  Hardware support guarantees that operations on synchronization primitives only ever take one step
Semaphores A semaphore is a flag that can be raised or lowered in one step Semaphores were flags that railroad engineers would use when entering a shared track Only one side of the semaphore can ever be red! (Can both be green?)
Semaphores set() and reset() can be thought of as lock() and unlock() Calls to lock() when the semaphore is already locked cause the thread to  block . Pitfalls: Must “bind” semaphores to particular objects; must remember to unlock correctly
The “corrected” example Thread 1: void foo() { sem.lock(); x++; y = x; sem.unlock(); } Thread 2: void bar() { sem.lock(); y++; x+=3; sem.unlock(); } Global var “Semaphore sem = new Semaphore();” guards access to x & y
Condition Variables A condition variable notifies threads that a particular condition has been met  Inform another thread that a queue now contains elements to pull from (or that it’s empty – request more elements!) Pitfall: What if nobody’s listening?
The final example Thread 1: void foo() { sem.lock(); x++; y = x; fooDone = true; sem.unlock(); fooFinishedCV.notify(); } Thread 2: void bar() { sem.lock(); if(!fooDone) fooFinishedCV.wait(sem); y++; x+=3; sem.unlock(); } Global vars: Semaphore sem = new Semaphore(); ConditionVar fooFinishedCV = new ConditionVar(); boolean fooDone = false;
Too Much Synchronization? Deadlock Synchronization becomes even more complicated when multiple locks can be used Can cause entire system to “get stuck” Thread A: semaphore1.lock(); semaphore2.lock(); /* use data guarded by  semaphores */ semaphore1.unlock();  semaphore2.unlock(); Thread B: semaphore2.lock(); semaphore1.lock(); /* use data guarded by  semaphores */ semaphore1.unlock();  semaphore2.unlock(); (Image: RPI CSCI.4210 Operating Systems notes)
The Moral: Be Careful! Synchronization is hard Need to consider all possible shared state Must keep locks organized and use them consistently and correctly Knowing there are bugs may be tricky; fixing them can be even worse! Keeping shared state to a minimum reduces total system complexity
Fundamentals of Networking
Sockets: The Internet = tubes? A socket is the basic network interface Provides a two-way “pipe” abstraction between two applications Client creates a socket, and connects to the server, who receives a socket representing the other side
Ports Within an IP address, a  port  is a sub-address identifying a listening program Allows multiple clients to connect to a server at once
What makes this work? Underneath the socket layer are several more protocols Most important are TCP and IP (which are used hand-in-hand so often, they’re often spoken of as one protocol: TCP/IP) Even more low-level protocols handle how data is sent over Ethernet wires, or how bits are sent through the air using 802.11 wireless…
Why is This Necessary? Not actually tube-like “underneath the hood” Unlike phone system (circuit switched), the  packet switched  Internet uses many routes at once
Networking Issues If a party to a socket disconnects, how much data did they receive? …  Did they crash? Or did a machine in the middle? Can someone in the middle intercept/modify our data? Traffic congestion makes switch/router topology important for efficient throughput
Conclusions Processing more data means using more machines at the same time Cooperation between processes requires synchronization Designing real distributed systems requires consideration of networking topology Next time: How MapReduce works

More Related Content

PPT
Google: Cluster computing and MapReduce: Introduction to Distributed System D...
tugrulh
 
PPT
Role of locking
Dr. C.V. Suresh Babu
 
PDF
Introducing Deep learning with Matlab
ICTperspectives
 
PPTX
Deep Learning - CNN and RNN
Ashray Bhandare
 
PDF
Brian Klumpe Unification of Producer Consumer Key Pairs
Brian_Klumpe
 
PDF
RNN and its applications
Sungjoon Choi
 
PDF
stacks2
Mohamed Elsayed
 
PPTX
Convolutional Neural Network (CNN) - image recognition
YUNG-KUEI CHEN
 
Google: Cluster computing and MapReduce: Introduction to Distributed System D...
tugrulh
 
Role of locking
Dr. C.V. Suresh Babu
 
Introducing Deep learning with Matlab
ICTperspectives
 
Deep Learning - CNN and RNN
Ashray Bhandare
 
Brian Klumpe Unification of Producer Consumer Key Pairs
Brian_Klumpe
 
RNN and its applications
Sungjoon Choi
 
Convolutional Neural Network (CNN) - image recognition
YUNG-KUEI CHEN
 

Viewers also liked (6)

PPT
Parallel Programming Primer 1
mobius.cn
 
PPT
Lec3 Dfs
mobius.cn
 
PPT
Lec2 Mapred
mobius.cn
 
PPT
Lec4 Clustering
mobius.cn
 
PPT
Lecture 1 (distributed systems)
Fazli Amin
 
PPT
Lec5 Pagerank
mobius.cn
 
Parallel Programming Primer 1
mobius.cn
 
Lec3 Dfs
mobius.cn
 
Lec2 Mapred
mobius.cn
 
Lec4 Clustering
mobius.cn
 
Lecture 1 (distributed systems)
Fazli Amin
 
Lec5 Pagerank
mobius.cn
 
Ad

Similar to Lec1 Intro (20)

PPT
Introduction to Cluster Computing and Map Reduce (from Google)
Sri Prasanna
 
PPT
Introduction & Parellelization on large scale clusters
Sri Prasanna
 
PPT
Distributed computing presentation
Delhi/NCR HUG
 
ODP
Multithreading 101
Tim Penhey
 
PDF
CN QNAs.pdf
ssuser9da62a
 
PDF
Software and the Concurrency Revolution : Notes
Subhajit Sahu
 
PPT
Again music
variable_orr
 
PPT
Introto netthreads-090906214344-phpapp01
Aravindharamanan S
 
PPT
Operating System 4
tech2click
 
PPT
Operating System 4 1193308760782240 2
mona_hakmy
 
PDF
Computer Network Theory Part 4
NishatTasnimAli
 
PPT
Processes, Threads and Scheduler
Munazza-Mah-Jabeen
 
PDF
CH04.pdf
ImranKhan880955
 
PPTX
Osi model
samriti_talwar
 
PPTX
Networking threads
Nilesh Pawar
 
PPT
1 osi model
SpacSec
 
PPT
Osi , tcp/ip protocol and Addressing
marwan aldulaimy
 
PDF
The Thread Chapter 4 of Operating System
mohammadhaidarayoobi
 
PDF
Introducing Parallel Pixie Dust
Jason Hearne-McGuiness
 
PDF
Significance
Julie May
 
Introduction to Cluster Computing and Map Reduce (from Google)
Sri Prasanna
 
Introduction & Parellelization on large scale clusters
Sri Prasanna
 
Distributed computing presentation
Delhi/NCR HUG
 
Multithreading 101
Tim Penhey
 
CN QNAs.pdf
ssuser9da62a
 
Software and the Concurrency Revolution : Notes
Subhajit Sahu
 
Again music
variable_orr
 
Introto netthreads-090906214344-phpapp01
Aravindharamanan S
 
Operating System 4
tech2click
 
Operating System 4 1193308760782240 2
mona_hakmy
 
Computer Network Theory Part 4
NishatTasnimAli
 
Processes, Threads and Scheduler
Munazza-Mah-Jabeen
 
CH04.pdf
ImranKhan880955
 
Osi model
samriti_talwar
 
Networking threads
Nilesh Pawar
 
1 osi model
SpacSec
 
Osi , tcp/ip protocol and Addressing
marwan aldulaimy
 
The Thread Chapter 4 of Operating System
mohammadhaidarayoobi
 
Introducing Parallel Pixie Dust
Jason Hearne-McGuiness
 
Significance
Julie May
 
Ad

Lec1 Intro

  • 1. Distributed Computing Seminar Lecture 1: Introduction to Distributed Computing & Systems Background Christophe Bisciglia, Aaron Kimball, & Sierra Michels-Slettvet Summer 2007 Except where otherwise noted, the contents of this presentation are © Copyright 2007 University of Washington and are licensed under the Creative Commons Attribution 2.5 License.
  • 2. Course Overview 5 lectures 1 Introduction 2 Technical Side: MapReduce & GFS 2 Theoretical: Algorithms for distributed computing Readings + Questions nightly Readings: http://code.google.com/edu/content/submissions/mapreduce-minilecture/listing.html Questions: http://code.google.com/edu/content/submissions/mapreduce-minilecture/MapReduceMiniSeriesReadingQuestions.doc
  • 3. Outline Introduction to Distributed Computing Parallel vs. Distributed Computing History of Distributed Computing Parallelization and Synchronization Networking Basics
  • 4. Computer Speedup Moore’s Law: “ The density of transistors on a chip doubles every 18 months, for the same cost” (1965) Image: Tom’s Hardware and not subject to the Creative Commons license applicable to the rest of this work. Image: Tom’s Hardware
  • 5. Scope of problems What can you do with 1 computer? What can you do with 100 computers? What can you do with an entire data center?
  • 6. Distributed problems Rendering multiple frames of high-quality animation Image: DreamWorks Animation and not subject to the Creative Commons license applicable to the rest of this work.
  • 7. Distributed problems Simulating several hundred or thousand characters Happy Feet © Kingdom Feature Productions; Lord of the Rings © New Line Cinema, neither image is subject to the Creative Commons license applicable to the rest of the work.
  • 8. Distributed problems Indexing the web (Google) Simulating an Internet-sized network for networking experiments (PlanetLab) Speeding up content delivery (Akamai) What is the key attribute that all these examples have in common?
  • 9. Parallel vs. Distributed Parallel computing can mean: Vector processing of data Multiple CPUs in a single computer Distributed computing is multiple CPUs across many computers over the network
  • 10. A Brief History… 1975-85 Parallel computing was favored in the early years Primarily vector-based at first Gradually more thread-based parallelism was introduced Image: Computer Pictures Database and Cray Research Corp and is not subject to the Creative Commons license applicable to the rest of this work.
  • 11. “ Massively parallel architectures” start rising in prominence Message Passing Interface (MPI) and other libraries developed Bandwidth was a big problem A Brief History… 1985-95
  • 12. A Brief History… 1995-Today Cluster/grid architecture increasingly dominant Special node machines eschewed in favor of COTS technologies Web-wide cluster software Companies like Google take this to the extreme
  • 14. Parallelization Idea Parallelization is “easy” if processing can be cleanly split into n units:
  • 15. Parallelization Idea (2) In a parallel computation, we would like to have as many threads as we have processors. e.g., a four-processor computer would be able to run four threads at the same time.
  • 18. Parallelization Pitfalls But this model is too simple! How do we assign work units to worker threads? What if we have more work units than threads? How do we aggregate the results at the end? How do we know all the workers have finished? What if the work cannot be divided into completely separate tasks? What is the common theme of all of these problems?
  • 19. Parallelization Pitfalls (2) Each of these problems represents a point at which multiple threads must communicate with one another, or access a shared resource. Golden rule: Any memory that can be used by multiple threads must have an associated synchronization system !
  • 20. What is Wrong With This? Thread 1: void foo() { x++; y = x; } Thread 2: void bar() { y++; x+=3; } If the initial state is y = 0, x = 6, what happens after these threads finish running?
  • 21. Multithreaded = Unpredictability When we run a multithreaded program, we don’t know what order threads run in, nor do we know when they will interrupt one another. Thread 1: void foo() { eax = mem[x]; inc eax; mem[x] = eax; ebx = mem[x]; mem[y] = ebx; } Thread 2: void bar() { eax = mem[y]; inc eax; mem[y] = eax; eax = mem[x]; add eax, 3; mem[x] = eax; } Many things that look like “one step” operations actually take several steps under the hood:
  • 22. Multithreaded = Unpredictability This applies to more than just integers: Pulling work units from a queue Reporting work back to master unit Telling another thread that it can begin the “next phase” of processing … All require synchronization!
  • 23. Synchronization Primitives A synchronization primitive is a special shared variable that guarantees that it can only be accessed atomically . Hardware support guarantees that operations on synchronization primitives only ever take one step
  • 24. Semaphores A semaphore is a flag that can be raised or lowered in one step Semaphores were flags that railroad engineers would use when entering a shared track Only one side of the semaphore can ever be red! (Can both be green?)
  • 25. Semaphores set() and reset() can be thought of as lock() and unlock() Calls to lock() when the semaphore is already locked cause the thread to block . Pitfalls: Must “bind” semaphores to particular objects; must remember to unlock correctly
  • 26. The “corrected” example Thread 1: void foo() { sem.lock(); x++; y = x; sem.unlock(); } Thread 2: void bar() { sem.lock(); y++; x+=3; sem.unlock(); } Global var “Semaphore sem = new Semaphore();” guards access to x & y
  • 27. Condition Variables A condition variable notifies threads that a particular condition has been met Inform another thread that a queue now contains elements to pull from (or that it’s empty – request more elements!) Pitfall: What if nobody’s listening?
  • 28. The final example Thread 1: void foo() { sem.lock(); x++; y = x; fooDone = true; sem.unlock(); fooFinishedCV.notify(); } Thread 2: void bar() { sem.lock(); if(!fooDone) fooFinishedCV.wait(sem); y++; x+=3; sem.unlock(); } Global vars: Semaphore sem = new Semaphore(); ConditionVar fooFinishedCV = new ConditionVar(); boolean fooDone = false;
  • 29. Too Much Synchronization? Deadlock Synchronization becomes even more complicated when multiple locks can be used Can cause entire system to “get stuck” Thread A: semaphore1.lock(); semaphore2.lock(); /* use data guarded by semaphores */ semaphore1.unlock(); semaphore2.unlock(); Thread B: semaphore2.lock(); semaphore1.lock(); /* use data guarded by semaphores */ semaphore1.unlock(); semaphore2.unlock(); (Image: RPI CSCI.4210 Operating Systems notes)
  • 30. The Moral: Be Careful! Synchronization is hard Need to consider all possible shared state Must keep locks organized and use them consistently and correctly Knowing there are bugs may be tricky; fixing them can be even worse! Keeping shared state to a minimum reduces total system complexity
  • 32. Sockets: The Internet = tubes? A socket is the basic network interface Provides a two-way “pipe” abstraction between two applications Client creates a socket, and connects to the server, who receives a socket representing the other side
  • 33. Ports Within an IP address, a port is a sub-address identifying a listening program Allows multiple clients to connect to a server at once
  • 34. What makes this work? Underneath the socket layer are several more protocols Most important are TCP and IP (which are used hand-in-hand so often, they’re often spoken of as one protocol: TCP/IP) Even more low-level protocols handle how data is sent over Ethernet wires, or how bits are sent through the air using 802.11 wireless…
  • 35. Why is This Necessary? Not actually tube-like “underneath the hood” Unlike phone system (circuit switched), the packet switched Internet uses many routes at once
  • 36. Networking Issues If a party to a socket disconnects, how much data did they receive? … Did they crash? Or did a machine in the middle? Can someone in the middle intercept/modify our data? Traffic congestion makes switch/router topology important for efficient throughput
  • 37. Conclusions Processing more data means using more machines at the same time Cooperation between processes requires synchronization Designing real distributed systems requires consideration of networking topology Next time: How MapReduce works

Editor's Notes

  • #21: There are multiple possible final states. Y is definitely a problem, because we don’t know if it will be “1” or “7”… but X can also be 7, 10, or 11!
  • #22: Inform students that the term we want here is “race condition”
  • #27: Ask: are there still any problems? (Yes – we still have two possible outcomes. We want some other system that allows us to serialize access on an event.)
  • #28: Go over wait() / notify() / broadcast() --- must be combined with a semaphore!