DOC PREVIEW
Rose-Hulman CSSE 332 - Concurrency

This preview shows page 1-2-20-21 out of 21 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

ConcurrencyTodayConcurrencyProblemsRace conditionExample 1: A program with threadsMem[Mailcount] = 25;Problem 1What’s causing the problem?How would you prevent the problem?How to prevent the problem?Slide 12How do processes interact with each other?Slide 14Slide 15Requirements for a mutual exclusion solutionEnforcing Mutual ExclusionFour different approaches1. Hardware supportDisadvantages2. Hardware support - special machine instructionsConcurrencyTodayLab 4 and homework 16 are both available and can be accessed from the schedule pageToday’s slides:http://www.rose-hulman.edu/class/csse/csse332/200920/Slides/defoe/Concurrency-Intro-Hardware-Support-Chidanandan.pptConcurrencySingle-processor, multi-programmed systemsInterleaving processes More efficient utilization of the processor Results in better system performance.Multi-processor systems Processes run at the same instance of time on different processors Interleaving and overlapping processesProblemsRelative speed of execution of processes cannot be predicted – do not know which process will run next.Variables and resources shared by processes.OS has more difficulty allocating resources. For example, a process requests a communication link, gets the link, but then times out. Should the OS give the communication link to some other process?Difficult to locate programming errors as program behavior cannot be replicated.Race conditionA condition where two or more threads/processes modify a shared resource and the final result depends on the relative timing of their execution.A mail server for an organization manages the e-mail. The mail-server has to keep track of the number of e-mails received from the start of the day. The receipt of an e-mail is handled by one of the several worker threads. Each time an e-mail is received, the thread must update MAILCOUNT using the following assembly language routine.LOAD MailCount #Acc = Mem[MailCount]ADD 1 #Acc= Acc + 1STORE MailCount # Mem[MailCount] = AccExample 1: A program with threadsMem[Mailcount] = 25;Thread 1Load MailCount # Acc = 25Add 1 # Acc = Acc + 1 = 26;Store MailCount # Mem[MailCount] = 26Thread 2Load MailCount # Acc = 25Add 1 # Acc = Acc+ 1 = 26Store MailCount # Mem[MailCount] = 26Problem 1Given the following code segment that is shared by two processes, show with a sequence of executions, how a race condition can affect the output of the two processes when they concurrently access the shared code and data. Assume a single-processor, multi-programmed system.void echo(){ chin = getchar(); //Accept keyboard input. chout = chin; putchar(chout); //Display input value to the output device}• When using shared variables and shared routines•Process behavior or thread behavior •must be predictable •must be independent of the speed at which its execution is carried out relative to the speed of other concurrent processes. What’s causing the problem?How would you prevent the problem?How to prevent the problem?Restrict access to shared variables and resources such that only when a process/ thread has completed execution of the shared code (i.e. checking, modifying and reacting to a shared variable) will another process be allowed to execute the shared code.The shared code that has to be protected is called the critical section.The principle of allowing one process/thread access to a critical resource at a given time is called mutual exclusion.Critical section – A section of code that requires access to shared resources and that may not be executed while another process is in a corresponding section of code that accesses the same shared resources.Mutual exclusion – The requirement that while one process is in a CS that accesses shared resources, no other process may be in a CS that accesses the same set of shared resources.Race condition – A condition where two or more threads/processes modify a shared resource and the final result depends on the relative timing of their execution.Deadlock – Processes are permanently blocked and waiting on events that can only be triggered by other blocked processesHow do processes interact with each other?Processes unaware of each other are said to be in competition with each other. They are independent of each other, do not share code or variables. May require common resources, e.g., a disk block or a printer.Influence on other processesOutput will not be affectedProcesses may experience delay Control problems facedNeed for mutual exclusion Deadlock preventionStarvationHow do processes interact with each other?Processes indirectly aware of each other Any process that accesses shared data or code knows that other processes are potentially modifying/accessing the shared data/code. Such processes are said to co-operate by sharing.Influence on other processesOutputs may be interdependentA process may experience delayControl problems Mutex, deadlock, and starvationAlso,Data is accessed both for read and write. Write accesses need to be mutually exclusive.Data coherence needs to be maintainedHow do processes interact with each other?Processes directly aware of each other may communicate directly with each other and are said to co-operate using communication.Processes are not competing. Have a common goal and co-operate.Mutual exclusion need not be enforced since there is typically no common data or resource.Communication is through message passing primitives.Can cause deadlock and starvation e.g. 1: Two processes are both blocked waiting for communication from each other.Requirements for a mutual exclusion solutionEnforce mutexA process that halts in its CS must not block other processes indefinitely.Process waiting for CS must not be waiting indefinitely – no deadlock, no starvationIf there is no process in the CS, no process wanting to enter the CS must be denied access.No assumptions are made about the relative speeds or number of processes.A process may remain in its CS for a finite period of time.Enforcing Mutual ExclusionFuntion(){ <non-CS> enter_critical_section(); <CS> exit_critical_section(); <non-CS> }Four different approachesHardware supportSoftware-defined approachesSupport from the OS Support from the programming language.1. Hardware supportvoid func(){<non-CS> /* disable interrupts */


View Full Document

Rose-Hulman CSSE 332 - Concurrency

Download Concurrency
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Concurrency and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Concurrency 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?