• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Topic 4: Concurrency
 

Topic 4: Concurrency

on

  • 344 views

Cloud Computing Workshop 2013, ITU

Cloud Computing Workshop 2013, ITU

Statistics

Views

Total Views
344
Views on SlideShare
344
Embed Views
0

Actions

Likes
0
Downloads
27
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Topic 4: Concurrency Topic 4: Concurrency Presentation Transcript

    • 4: ConcurrencyZubair Nabizubair.nabi@itu.edu.pkApril 18, 2013Zubair Nabi 4: Concurrency April 18, 2013 1 / 22
    • Outline1 Introduction2 Concurrency in Practice3 Liveness4 Message passing5 TransactionsZubair Nabi 4: Concurrency April 18, 2013 2 / 22
    • Outline1 Introduction2 Concurrency in Practice3 Liveness4 Message passing5 TransactionsZubair Nabi 4: Concurrency April 18, 2013 3 / 22
    • ExecutionProcessProgram in executionZubair Nabi 4: Concurrency April 18, 2013 4 / 22
    • ExecutionProcessProgram in executionUnit of protection and resource allocationZubair Nabi 4: Concurrency April 18, 2013 4 / 22
    • ExecutionProcessProgram in executionUnit of protection and resource allocationPrivate address space and one or more threadsZubair Nabi 4: Concurrency April 18, 2013 4 / 22
    • ExecutionProcessProgram in executionUnit of protection and resource allocationPrivate address space and one or more threadsThreadAn entity managed by the schedulerZubair Nabi 4: Concurrency April 18, 2013 4 / 22
    • ExecutionProcessProgram in executionUnit of protection and resource allocationPrivate address space and one or more threadsThreadAn entity managed by the schedulerRepresents an individual execution contextZubair Nabi 4: Concurrency April 18, 2013 4 / 22
    • ExecutionProcessProgram in executionUnit of protection and resource allocationPrivate address space and one or more threadsThreadAn entity managed by the schedulerRepresents an individual execution contextRuns within the address space of the containing processZubair Nabi 4: Concurrency April 18, 2013 4 / 22
    • ConcurrencySeemingly doing many things at onceZubair Nabi 4: Concurrency April 18, 2013 5 / 22
    • ConcurrencySeemingly doing many things at onceWith a single processor: Interleaving of different executionsZubair Nabi 4: Concurrency April 18, 2013 5 / 22
    • ConcurrencySeemingly doing many things at onceWith a single processor: Interleaving of different executions1 Process/OSZubair Nabi 4: Concurrency April 18, 2013 5 / 22
    • ConcurrencySeemingly doing many things at onceWith a single processor: Interleaving of different executions1 Process/OS2 Inter-processZubair Nabi 4: Concurrency April 18, 2013 5 / 22
    • ConcurrencySeemingly doing many things at onceWith a single processor: Interleaving of different executions1 Process/OS2 Inter-process3 Intra-processZubair Nabi 4: Concurrency April 18, 2013 5 / 22
    • ConcurrencySeemingly doing many things at onceWith a single processor: Interleaving of different executions1 Process/OS2 Inter-process3 Intra-processWith multiple processorsTrue parallelismZubair Nabi 4: Concurrency April 18, 2013 5 / 22
    • AdvantagesOverlap computation and I/OZubair Nabi 4: Concurrency April 18, 2013 6 / 22
    • AdvantagesOverlap computation and I/OSimplify code structuringZubair Nabi 4: Concurrency April 18, 2013 6 / 22
    • AdvantagesOverlap computation and I/OSimplify code structuringImprove responsivenessZubair Nabi 4: Concurrency April 18, 2013 6 / 22
    • AdvantagesOverlap computation and I/OSimplify code structuringImprove responsivenessSeamless use of multiple CPUsZubair Nabi 4: Concurrency April 18, 2013 6 / 22
    • Critical sectionsRecurring problem: Two (or more) threads trying to solve the sameproblem concurrentlyZubair Nabi 4: Concurrency April 18, 2013 7 / 22
    • Critical sectionsRecurring problem: Two (or more) threads trying to solve the sameproblem concurrentlyOnly one thread should be allowed to access the piece of code thatshould never be concurrently executedZubair Nabi 4: Concurrency April 18, 2013 7 / 22
    • Critical sectionsRecurring problem: Two (or more) threads trying to solve the sameproblem concurrentlyOnly one thread should be allowed to access the piece of code thatshould never be concurrently executedKnown as a critical sectionZubair Nabi 4: Concurrency April 18, 2013 7 / 22
    • Critical sectionsRecurring problem: Two (or more) threads trying to solve the sameproblem concurrentlyOnly one thread should be allowed to access the piece of code thatshould never be concurrently executedKnown as a critical sectionOnly one thread should be executing within a critical sectionZubair Nabi 4: Concurrency April 18, 2013 7 / 22
    • Critical sectionsRecurring problem: Two (or more) threads trying to solve the sameproblem concurrentlyOnly one thread should be allowed to access the piece of code thatshould never be concurrently executedKnown as a critical sectionOnly one thread should be executing within a critical sectionKnown as mutual exclusionZubair Nabi 4: Concurrency April 18, 2013 7 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Zubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingZubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingSemaphores: Implemented as an integer and a queueZubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingSemaphores: Implemented as an integer and a queueAbility to wait() and signal()Zubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingSemaphores: Implemented as an integer and a queueAbility to wait() and signal()Can also provide condition synchronizationZubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingSemaphores: Implemented as an integer and a queueAbility to wait() and signal()Can also provide condition synchronizationCorrect use requires considerable care (forgetting to call wait() orsignal())Zubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingSemaphores: Implemented as an integer and a queueAbility to wait() and signal()Can also provide condition synchronizationCorrect use requires considerable care (forgetting to call wait() orsignal())Monitors: Explicitly declare variables and tag code as using thosevariablesZubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingSemaphores: Implemented as an integer and a queueAbility to wait() and signal()Can also provide condition synchronizationCorrect use requires considerable care (forgetting to call wait() orsignal())Monitors: Explicitly declare variables and tag code as using thosevariablesCompiler automatically declares and manages underlying primitives formutual exclusion or synchronizationZubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Ensuring mutexLocks: Ability to lock and unlock a critical section (based on an atomicoperation enabled by the hardware)Overhead of busy waitingSemaphores: Implemented as an integer and a queueAbility to wait() and signal()Can also provide condition synchronizationCorrect use requires considerable care (forgetting to call wait() orsignal())Monitors: Explicitly declare variables and tag code as using thosevariablesCompiler automatically declares and manages underlying primitives formutual exclusion or synchronizationRelated routines are combined togetherZubair Nabi 4: Concurrency April 18, 2013 8 / 22
    • Outline1 Introduction2 Concurrency in Practice3 Liveness4 Message passing5 TransactionsZubair Nabi 4: Concurrency April 18, 2013 9 / 22
    • Linux KernelKernel provides spinlocks and semaphoresZubair Nabi 4: Concurrency April 18, 2013 10 / 22
    • Linux KernelKernel provides spinlocks and semaphoresSpinlocks busy wait so only hold for short timeZubair Nabi 4: Concurrency April 18, 2013 10 / 22
    • Linux KernelKernel provides spinlocks and semaphoresSpinlocks busy wait so only hold for short timeAlso provides reader-writer spinlock variantsZubair Nabi 4: Concurrency April 18, 2013 10 / 22
    • Linux KernelKernel provides spinlocks and semaphoresSpinlocks busy wait so only hold for short timeAlso provides reader-writer spinlock variantsAllows many readers or a single writerZubair Nabi 4: Concurrency April 18, 2013 10 / 22
    • JavaInspired by monitorsZubair Nabi 4: Concurrency April 18, 2013 11 / 22
    • JavaInspired by monitorsThrough the synchronize primitiveZubair Nabi 4: Concurrency April 18, 2013 11 / 22
    • JavaInspired by monitorsThrough the synchronize primitiveObjects already encapsulate data and methodsZubair Nabi 4: Concurrency April 18, 2013 11 / 22
    • JavaInspired by monitorsThrough the synchronize primitiveObjects already encapsulate data and methodsBlock synchronization is preferred over method synchronizationZubair Nabi 4: Concurrency April 18, 2013 11 / 22
    • JavaInspired by monitorsThrough the synchronize primitiveObjects already encapsulate data and methodsBlock synchronization is preferred over method synchronizationC# is similar too but requires explicit invocationZubair Nabi 4: Concurrency April 18, 2013 11 / 22
    • Outline1 Introduction2 Concurrency in Practice3 Liveness4 Message passing5 TransactionsZubair Nabi 4: Concurrency April 18, 2013 12 / 22
    • LivenessWant threads to make progressZubair Nabi 4: Concurrency April 18, 2013 13 / 22
    • LivenessWant threads to make progressTo make progress need to avoid:1 Deadlock: Threads sleep waiting for each otherZubair Nabi 4: Concurrency April 18, 2013 13 / 22
    • LivenessWant threads to make progressTo make progress need to avoid:1 Deadlock: Threads sleep waiting for each other2 Livelock: Threads execute but make no progressZubair Nabi 4: Concurrency April 18, 2013 13 / 22
    • LivenessWant threads to make progressTo make progress need to avoid:1 Deadlock: Threads sleep waiting for each other2 Livelock: Threads execute but make no progressFor good performance also need to ensure:Zubair Nabi 4: Concurrency April 18, 2013 13 / 22
    • LivenessWant threads to make progressTo make progress need to avoid:1 Deadlock: Threads sleep waiting for each other2 Livelock: Threads execute but make no progressFor good performance also need to ensure:1 No starvation: Each thread must make progressZubair Nabi 4: Concurrency April 18, 2013 13 / 22
    • LivenessWant threads to make progressTo make progress need to avoid:1 Deadlock: Threads sleep waiting for each other2 Livelock: Threads execute but make no progressFor good performance also need to ensure:1 No starvation: Each thread must make progress2 Minimality: No unnecessary waiting or signallingZubair Nabi 4: Concurrency April 18, 2013 13 / 22
    • DeadlockSet of threads go to sleep and cannot wake upZubair Nabi 4: Concurrency April 18, 2013 14 / 22
    • DeadlockSet of threads go to sleep and cannot wake upCan only be woken by another thread who is also asleepZubair Nabi 4: Concurrency April 18, 2013 14 / 22
    • DeadlockSet of threads go to sleep and cannot wake upCan only be woken by another thread who is also asleepDealing with deadlocks:1 Ensure it never happens: Prevention and avoidanceZubair Nabi 4: Concurrency April 18, 2013 14 / 22
    • DeadlockSet of threads go to sleep and cannot wake upCan only be woken by another thread who is also asleepDealing with deadlocks:1 Ensure it never happens: Prevention and avoidance2 Let it happen but recover: Detection and recoveryZubair Nabi 4: Concurrency April 18, 2013 14 / 22
    • DeadlockSet of threads go to sleep and cannot wake upCan only be woken by another thread who is also asleepDealing with deadlocks:1 Ensure it never happens: Prevention and avoidance2 Let it happen but recover: Detection and recovery3 Ignore it: Let the programmer deal with itZubair Nabi 4: Concurrency April 18, 2013 14 / 22
    • LivelockDeadlock is relatively easy to detect by humansZubair Nabi 4: Concurrency April 18, 2013 15 / 22
    • LivelockDeadlock is relatively easy to detect by humansLivelock is less easy to detect as threads continue to run (as opposed toblocking in deadlock) but do nothing usefulZubair Nabi 4: Concurrency April 18, 2013 15 / 22
    • LivelockDeadlock is relatively easy to detect by humansLivelock is less easy to detect as threads continue to run (as opposed toblocking in deadlock) but do nothing usefulPrevalent in code used to detect and handle deadlocksZubair Nabi 4: Concurrency April 18, 2013 15 / 22
    • LivelockDeadlock is relatively easy to detect by humansLivelock is less easy to detect as threads continue to run (as opposed toblocking in deadlock) but do nothing usefulPrevalent in code used to detect and handle deadlocksTwo threads detect a deadlock and try to step aside for each otherZubair Nabi 4: Concurrency April 18, 2013 15 / 22
    • Outline1 Introduction2 Concurrency in Practice3 Liveness4 Message passing5 TransactionsZubair Nabi 4: Concurrency April 18, 2013 16 / 22
    • Concurrency without shared dataOnly one thread can access any particular piece of dataZubair Nabi 4: Concurrency April 18, 2013 17 / 22
    • Concurrency without shared dataOnly one thread can access any particular piece of dataDifferent threads can own distinct chunks of dataZubair Nabi 4: Concurrency April 18, 2013 17 / 22
    • Concurrency without shared dataOnly one thread can access any particular piece of dataDifferent threads can own distinct chunks of dataEnsure concurrency by allowing other threads to ask for operations to bedone on their behalf (Dynamic invocation)Zubair Nabi 4: Concurrency April 18, 2013 17 / 22
    • Concurrency without shared dataOnly one thread can access any particular piece of dataDifferent threads can own distinct chunks of dataEnsure concurrency by allowing other threads to ask for operations to bedone on their behalf (Dynamic invocation)Can be thought of as general message passing (Similar to email)Zubair Nabi 4: Concurrency April 18, 2013 17 / 22
    • Concurrency without shared dataOnly one thread can access any particular piece of dataDifferent threads can own distinct chunks of dataEnsure concurrency by allowing other threads to ask for operations to bedone on their behalf (Dynamic invocation)Can be thought of as general message passing (Similar to email)Can be used to implement RPCZubair Nabi 4: Concurrency April 18, 2013 17 / 22
    • AdvantagesAvoids race conditionZubair Nabi 4: Concurrency April 18, 2013 18 / 22
    • AdvantagesAvoids race conditionProvides a flexible APIZubair Nabi 4: Concurrency April 18, 2013 18 / 22
    • AdvantagesAvoids race conditionProvides a flexible APIBatching: Batch X messages togetherZubair Nabi 4: Concurrency April 18, 2013 18 / 22
    • AdvantagesAvoids race conditionProvides a flexible APIBatching: Batch X messages togetherScheduling: Choose the when, who, and which of message receiptZubair Nabi 4: Concurrency April 18, 2013 18 / 22
    • AdvantagesAvoids race conditionProvides a flexible APIBatching: Batch X messages togetherScheduling: Choose the when, who, and which of message receiptBroadcast: Send messages to many recipientsZubair Nabi 4: Concurrency April 18, 2013 18 / 22
    • AdvantagesAvoids race conditionProvides a flexible APIBatching: Batch X messages togetherScheduling: Choose the when, who, and which of message receiptBroadcast: Send messages to many recipientsUsed as the basis for some languages, such as Linda, occam, and ErlangZubair Nabi 4: Concurrency April 18, 2013 18 / 22
    • ErlangFunctional language from the mid 80sZubair Nabi 4: Concurrency April 18, 2013 19 / 22
    • ErlangFunctional language from the mid 80sCheap, lightweight, language-level processesZubair Nabi 4: Concurrency April 18, 2013 19 / 22
    • ErlangFunctional language from the mid 80sCheap, lightweight, language-level processesEach variable is assigned only once (Immutable afterwards)Zubair Nabi 4: Concurrency April 18, 2013 19 / 22
    • ErlangFunctional language from the mid 80sCheap, lightweight, language-level processesEach variable is assigned only once (Immutable afterwards)Explicit message passing via in order message delivery to local mailboxZubair Nabi 4: Concurrency April 18, 2013 19 / 22
    • ErlangFunctional language from the mid 80sCheap, lightweight, language-level processesEach variable is assigned only once (Immutable afterwards)Explicit message passing via in order message delivery to local mailboxUsed to implement Facebook ChatZubair Nabi 4: Concurrency April 18, 2013 19 / 22
    • Outline1 Introduction2 Concurrency in Practice3 Liveness4 Message passing5 TransactionsZubair Nabi 4: Concurrency April 18, 2013 20 / 22
    • TransactionsEither executes correctly (commits) or has no effect at allZubair Nabi 4: Concurrency April 18, 2013 21 / 22
    • TransactionsEither executes correctly (commits) or has no effect at allProperties:1 Atomicity: Either all or none of the operations are performedZubair Nabi 4: Concurrency April 18, 2013 21 / 22
    • TransactionsEither executes correctly (commits) or has no effect at allProperties:1 Atomicity: Either all or none of the operations are performed2 Consistency: A transaction transforms the system from one consistentstate to anotherZubair Nabi 4: Concurrency April 18, 2013 21 / 22
    • TransactionsEither executes correctly (commits) or has no effect at allProperties:1 Atomicity: Either all or none of the operations are performed2 Consistency: A transaction transforms the system from one consistentstate to another3 Isolation: Each transaction gives the notion of sandboxing from theconcurrent effects of othersZubair Nabi 4: Concurrency April 18, 2013 21 / 22
    • TransactionsEither executes correctly (commits) or has no effect at allProperties:1 Atomicity: Either all or none of the operations are performed2 Consistency: A transaction transforms the system from one consistentstate to another3 Isolation: Each transaction gives the notion of sandboxing from theconcurrent effects of others4 Durability: The effects of committed transactions survive subsequentsystem failuresZubair Nabi 4: Concurrency April 18, 2013 21 / 22
    • ReferencesOperating systems: Concurrent and distributed software design. JeanBacon and Tim Harris, Addison Wesley, 2003Zubair Nabi 4: Concurrency April 18, 2013 22 / 22