Chapter 5 Concurrency: Mutual Exclusion and Synchronization Part 1

1
Chapter 5ConcurrencyMutual Exclusion and
Synchronization(Part 1)

• CS 472 Operating Systems
• Indiana University Purdue University Fort Wayne

2
Outline of Chapter 5 Part 1

• Concurrent programming overview
• Control problems
• Lack of mutual exclusion
• Synchronization
• Deadlock
• Starvation

3
Concurrent programming

• Single processor system
• Simulated parallelism
• Process execution interleaved
• Multiprocessor and distributed systems
• True parallelism possible
• Simultaneous execution of processes
• Process execution overlaps
• Concurrent programming is done in the context of
  both types of systems

4
Concurrent programming

• Concurrent programming is concerned with the
  notions and techniques for expressing potential
  parallelism and for solving the resulting
  synchronization and communication problems
• The same problems exist on a single processor
  system as on a multiprocessor or distributed
  system
• The same techniques are used to deal with these
  problems
• A concurrent application should run equally well
  on any of these systems

5
Concurrent programming
6
Concurrent programming

• Language features may allow a programmer to
  request parallel execution
• The text uses the notation
• This suspends the current method
• Processes P1, P2, , and Pn then run
  concurrently
• When these processes all terminate, the current
  method is resumed
• The request to may be granted on a multiprocessor
  system or simulated on a single processor system
• In either case, the programmer has the
  responsibility to avoid deadlock and enforce
  mutual exclusion

parbegin( P1, P2, . . . , Pn )
7
Concurrent programming

• On a multiprocessor system, the compiler may
  choose a parallel solution without any programmer
  request
• Correctness is then the responsibility of the
  compiler

a bc de
reg1 bc reg2 de a reg1 reg2
compiler optimization
8
Basic rule of concurrent programming
No assumption may be made about the relative
speeds of processes

• It is not possible to predict when processes will
  be scheduled
• Correctness of a collection of concurrent
  programs must be guaranteed over all possible
  interleaved execution sequences
• To show incorrect, exhibit a scenario which
  gives incorrect results
• For example, a race condition scenario is when
  the results of two processes depend on which
  process performs an operation first

9
Concurrent programming

• Race condition example
• Assume a single processor system
• Both processes A and B share an array used as a
  stack and use shared variable SP as the array
  index
• Processes A and B both attempt to increment SP
• A and B push values onto the same stack location
  18

internal SP process
instruction register variable A
LOAD SP 17 17 A INC 18 17 B
LOAD SP 17 17 B INC 18 17 B
STORE SP 18 18 A STORE SP
18 18
timer interrupt
???
timer interrupt
should be 19
10
Concurrent programming
void echo ( ) chin getchar( ) chout
chin putchar( chout )

• Another example
• character echo method
• (see pp. 208 - 210)
• Assume a single-processor multiprogramming system
• A single copy of echo is shared among many
  processes
• Static variables chin and chout are shared
• Any process may call echo
• Problem violates the basic rule
• Characters might be lost or displayed twice
• Solution
• Allow only one process at a time to execute echo
• On a multiprocessor system, the same problems
  exist and the same solution works

11
Control problems with concurrency

• Control problems associated with concurrent
  programming are due to . . .
• Lack of mutual exclusion
• Deadlock
• Starvation

12
Typical process interactions

• There are three typical types of process
  interactions
• Competition for resources
• Cooperation by sharing
• Cooperation with direct communication
• These relationships may all be present in the
  same system
• Each of type of relationship (except the last)
  may exhibit any of the three control problems
• Cooperation by direct communication doesnt
  suffer from lack of mutual exclusion

13
Typical process interactions

• Competition for resources
• Involves unrelated batch jobs, interactive
  sessions, etc.
• Only a vague awareness of other processes
• Some resources must be checked out and returned
• Open( F, Input, Name )
• Close( F )
• Processes should not affect the state of shared
  resources

14
Typical process interactions

• Cooperation by sharing
• Processes must manage access to common shared
  resources with access rules
• Example shared memory
• Processes may read concurrently if writing is not
  allowed
• If writing is allowed, then mutual exclusion is
  necessary
• Typical situations
• Multiple processes collaborating on an
  application
• Online news service
• Airline seat reservation system

15
Typical process interactions

• Cooperation by direct communication
• Synchronization is provided by messages
• A mechanism is needed to pass messages
• Mutual exclusion is not needed
• Nothing is shared

16
(No Transcript)
17
Control problems with concurrency

• Lack of mutual exclusion
• Involves a shared critical resource
• Memory area, printer, etc.
• Only one process at a time may use the critical
  resource
• A critical section of a process is process code
  that accesses a critical resource
• Only one process at a time may enter a critical
  section associated with a critical resource
  (mutual exclusion)
• Note the analogy of trains on multiple lines
  crossing a single-line trestle
• Any facility supporting mutual exclusion must
  meet certain requirements (next slides)

18
Requirements for mutual exclusion

• Only one process at a time is allowed in its
  critical section for a given resource
• A process that halts in any non-critical section
  must do so without interfering with other
  processes
• A process requiring access to a critical section
  must not be delayed indefinitely
• No deadlock or starvation is allowed

19
Requirements for mutual exclusion

• When no process is in a critical section, any
  process that requests entry to its critical
  section must be permitted to enter without delay
• No assumptions may be made about relative process
  speeds or number of processors
• A process remains inside its critical section for
  a finite time only
• Good programming practice minimizes this time

20
Control problems with concurrency

• Deadlock
• Two or more processes wait forever for a
  resources held by other processes
• Example
• Process P1 owns resource R1 and P2 owns R2
• But P1 needs R2 to continue and P2 needs R1
• Example (actually livelock)
• P1 owns the printer and is preempted by a
  higher-priority process P2
• P2 needs the printer and does a busy wait until
  available
• P1 needs a time slice and is denied forever

21
Control problems with concurrency

• Starvation
• A process is not granted fair access to resources
  it needs and is indefinitely denied
• Could simply be due to timing, poor coincidence,
  etc.