Process Synchronization Ch. 4.4 – Cooperating Processes Ch. 7 – Concurrency

Cooperating Processes  Independent process cannot affect or be affected by the execution of another process.  Cooperating process can affect or be affected by the execution of another process

Advantages of process cooperation  Information sharing Allow concurrent access to data sources  Computation speed-up Sub-tasks can be executed in parallel  Modularity System functions can be divided into separate processes or threads  Convenience

Context Switches can Happen at Any Time  A process switch (full context switch) can happen at any time there is a mode switch into the kernel  This could be because of a: System call (semi-predictable) Timer (round robin, etc.) I/O interrupt (unblock some other process) Other interrupt, etc.  The programmer generally cannot predict at what point in a program this might happen

Preemption is Unpredictable  This means that the program’s work can be interrupted at any time (I.e. just after the completion of any instruction): Some other program gets to run for a while And the interrupted program eventually gets restarted exactly where it left off. After the other program (process) executes other instructions that we have no control over  This can lead to trouble if processes are not independent

Problems with Concurrent Execution  Concurrent processes (or threads) often need to share data (maintained either in shared memory or files) and resources  If there is no controlled access to shared data, execution of the processes on these data can interleave.  The results will then depend on the order in which data were modified i.e. the results are non-deterministic.

Shared Memory kernel process B process A shared memory

An Example: Bank Account A joint account. Each account holder accesses money at the same time – one deposits, the other withdraws. The bank’s computer is executing the routine below simultaneously as two processes running the same transaction processing program void update(acct,amount) { temp = getbalance(acct); temp += amount; putbalance(acct,temp); }

Banking Example void update(acct,amount) { temp = getbalance(acct); temp += amount; putbalance(acct,amount); } temp = 60 temp = putbalance (160) Initial balance = $60 A’s deposit = $100 B’s withdrawal = $50 Net balance = $110 A’s process: Process Switch! B’s process: temp = putbalance (10) temp = 60 What is the final bank balance?

Race Conditions  A situation such as this, where processes “race” against each other, causing possible errors, is called a race condition.  2 or more processes are reading/writing shared data and the final result depends on the order the processes have run  Can happen at the application level and the OS level

Printer queue example (OS level)  Printer queue – often implemented as a circular queue. Out = position of next item to be printed In = position of next empty slot.  lw or lpr File added to print queue  What happens if 2 processes requesting queuing of a print job at the same time? Each must access the variable “in”.

Dueling queueing Timeline (Process A) 1. Read in = Insert job at position 7 7. in++ (in = 8) 8. Exit lw Timeline (Process B) Read in = 7 3. Insert job at position 7 4. in++ (in = 8) 5. Exit lw What happened to B’s print job?

Producer-Consumer Problem  Paradigm for cooperating processes, producer process produces information that is consumed by a consumer process. unbounded-buffer places no practical limit on the size of the buffer. bounded-buffer assumes that there is a fixed buffer size.  Print queue is an example – processes putting jobs in queue, printer daemon taking jobs out. Daemon = process that runs continually and handles service requests

Basic Producer-Consumer Producer repeat produce item /*if buffer full, do nothing*/ while (counter ==n); insert item counter ++; forever Consumer repeat /* if buffer empty, do nothing*/ while (counter ==0); remove item counter--; consume item forever Shared data: (bounded buffer) Buff size = n Counter = 0

Problems with Basic algorithm  More than 1 process can access shared “counter” variable  Race condition can result in incorrect value for “counter”  Inefficient: Busy-wait checking value of counter

Producer-Consumer with Sleep Producer repeat produce item /*if buffer full, go to sleep*/ if (counter ==n) sleep(); insert item counter ++; If (count ==1) wakeup(consumer); forever Consumer repeat /* if buffer empty, go to sleep*/ if (counter ==0) sleep(); remove item counter--; if (count ==(n-1) wakeup (producer) consume item forever Shared data: (bounded buffer) Buff size = n Counter = 0

Problems  If counter has a value of 1..n-1, both processes are running, so both can access shared “counter” variable  Race condition can result in incorrect value for “counter”  Could lead to deadlock with both processes asleep

Could also lead to deadlock… Timeline (Consumer) 1. If (counter ==0) True Sleep() Timeline (Producer) Produce item 3. If (counter ==n) F 4. Insert item 5. Counter++ 6. If (counter == 1) T 7. Wakeup (consumer) 8. Wakeup call lost as consumer not sleeping Eventually both will be asleep - deadlock

Critical section  That part of the program where shared resources are accessed  When a process executes code that manipulates shared data (or resource), we say that the process is in a critical section (CS) (for that resource)  Entry and exit sections (small pieces of code) guard the critical section

The Critical Section Problem  CS’s can be thought of as sequences of instructions that are ‘tightly bound’ so no other process should interfere via interleaving or parallel execution.  The execution of CS’s must be mutually exclusive: At any time, only one process should be allowed to execute in a CS (even with multiple CPUs)  Therefore we need a system where each process must request permission to enter its CS, and we need a means to “administer” this

The Critical Section Problem  The section of code implementing this request is called the entry section  The critical section (CS) will be followed by an exit section, which opens the possibility of other processes entering their CS.  The remaining code is the remainder section RS  The critical section problem is to design the processes so that their results will not depend on the order in which their execution is interleaved.  We must also prevent deadlock and starvation.

Framework for analysis of solutions  Each process executes at nonzero speed but no assumption on the relative speed of n processes  General structure of a process:  Several CPUs may be present but memory hardware prevents simultaneous access to the same memory location  No assumptions about order of interleaved execution  The central problem is to design the entry and exit sections repeat entry section critical section exit section remainder section forever