Chapter 10: Atomic Actions, concurrent processes and reliability

1
Chapter 10 Atomic Actions, concurrent processes
and reliability
2
Atomic actions - background

• In some cases we need to have a number of related
  interactions between two processes, e.g.
  withdrawal from a bank account.
• In some cases we need to involve more than two
  processes in an interaction.
• When more than one process is involved we need to
  perform the joint activity indivisible as an
  atomic action.
• We saw the problems with the domino effect.

3
Atomic actions - definition

• An action is atomic if the processes performing
  it are not aware of the existence of any other
  active process, and no other active process is
  aware of the activity of the processes during the
  time the processes are performing the action.
• An action is atomic if the processes performing
  it do not communicate with other processes while
  the action is being performed.
• An action is atomic if the processes performing
  it can detect no state change except those
  performed by themselves and if they do not reveal
  their state changes until the action is complete.
• Actions are atomic if they can be considered, so
  far as other processes are concerned, to be
  indivisible and instantaneous, such that the
  effect on the system are as if they were
  interleaved as opposed to concurrent.

4
Atomic actions - continued

• One concurrent action can contain one or more
  other concurrent actions (nested actions).
• Ideally, all processes involved in an AA should
  obtain the resources they need before the action
  begins, and these resources should be returned
  after the action has completed.
• A more pragmatic approach is to allow processes
  to communicate with resource handlers.
• The processes should work in two phases one
  phase where they allocate new resources (growing
  phase) and one phase where they release resources
  (shrinking phase).
• Releasing resources early may make more difficult
  to recover if the atomic action fails, i.e.
  recoverable actions should not release any
  resources until the action is completed.

5
Atomic transactions

• In operating and database systems there is
  something called an atomic transaction.
• An atomic transaction is an atomic action that
  either succeeds or fails, and in the case of
  failure the state of the system is restored to
  that before the transaction started.
• This means that the system is never left in an
  inconsistent state.

6
Requirements for atomic actions

• The language requirements for expressing atomic
  actions are
• Well-defined boundariesStart, end and side
  boundary
• IndivisibilityResource managers excluded.
  Processes may enter an atomic action at any time,
  but there is a synchronization at the end.
• NestingAtomic actions can be nested.
• ConcurrencyIt should be possible to execute two
  atomic actions concurrently.
• Allow recovery procedures to be programmed

7
Atomic actions in Ada

entry First when not First_Here
isbegin First_Here true end First entry
First when not First_Here isbegin First_Here
true end First entry Finished when Release
or Finishedcount 3 is begin if
Finishedcount 0 then First_Here false
Sec_Here false Third_Here false
Release false else Release
true end if end Finished .

• Package body Action_X is protected
  Action_Controller is entry First
• entry Second
• entry Third
• entry Finished
• private
• First_Here boolean false
• Sec_Here boolean false
• Third_Here boolean false
• Release boolean false
• end Action_Controller
• protected body Action_Controller is entry First
  when not First_Here is begin
• First_Here true
• end First

8
Conversations

• Conversations is a way to implement atomic
  actions and backward error recovery. Dialogues is
  an alternative to Conversations.
• Action A with (P2,P3) doensure ltacceptance
  testgtby primary moduleelse by secondary
  moduleelse by else erroraction A

9
Asynchronous notification

• In order to write recoverable actions a process
  may need to notify another process that an
  exception has occurred
• There are two basic models
• Resumption, behaves like a software interrupt. It
  is possible to associate a specific thread with a
  certain interrupt (notification), e.g. Real-Time
  Java.
• Termination, asynchronous transfer of control
  (ATC). Ada and real-time Java support ATC.

10
The user need for asynchronous notification

• The basic need is to enable a quick response from
  a process (as opposed to polling)
• Error recovery, e.g. atomic actions
• Mode changes
• Scheduling using partial/imprecise computations
• User interrupts, a user may want to stop a
  process

11
Asynchronous event handling

• There is support for asynchronous event handling
  in
• POSIX
• Java
• Ada, asynchronous select statement

12
Chapter 11 Resource control

• We will focus on deadlocks

13
Deadlock

• Process P1 has exclusive access to resource R1
• Process P1 is waiting for another resource R2
• Process P2 has exclusive access to resource R2
• Process P2 is waiting for resource R1
• This is an example of a deadlock situation
• Livelock is almost the same thing but in this
  case the involved processes are executing busy
  waits

14
Necessary conditions for deadlock

• Mutual exclusionOnly one process can use a
  resource at once.
• Hold and waitThere must exist processes which
  are holding resources while waiting for others
• No preemptionA resource can only be released
  voluntarily by a process
• Circular waitA chain of processes must exist
  such that each process holds resources which are
  being requested by the next process in the chain

15
Methods for handling deadlock

• Deadlock prevention
• Deadlock avoidance
• Deadlock detection and recovery

16
Deadlock prevention

• Ensure that at least one of the four necessary
  deadlock conditions never occurs, e.g.
• Mutual exclusion difficult to do anything about
• Hold and wait request all necessary resources
  at once
• No preemption release all resources when the
  process cannot allocate a new resource
• Circular wait order the resources and allow only
  processes to allocate resources in increasing
  order

17
Deadlock avoidance

• A deadlock avoidance algorithm will examine
  dynamically the resource allocation state and
  take action (e.g. denying access to a free
  resource) to ensure that the system can never
  enter into deadlock.
• The idea is to keep the system in a safe state
• State number of resources available, number
  allocated and maximum demand of each process
• Bankers algorithm

18
Deadlock detection and recovery

• Resource allocation graphs
• One may kill one or more processes thus releasing
  their resources