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

19
Chapter 12 Real-time facilities
20
The notion of time

• The introduction of the notion of time can be
  described as three largely independent topics
• Interfacing with time, e.g. accessing clocks,
  delaying processes and programming time-outs
• Representing timing requirements, e.g.
  representing rates of execution and deadlines
• Satisfying timing requirements

21
Access to a clock

• This can be done in two ways
• By having direct access to the environments time
  frame, interrupts from the environment or
  international time trough radio signals (UTC
  Coordinated Universal Time)
• By using an internal hardware clock that gives an
  adequate approximation of time.

22
The clock packages in Ada

• There are two Ada packages that handle time
• The compulsory calendar package, a granularity no
  greater than 20 ms.
• The optional real-time package , a granularity no
  greater than 1 ms.

23
Clocks in Real-Time Java

• Standard Java supports wall clock time in a
  similar way as the Ada calendar package
• Real-time Java extends these capabilities with
  high resolution time types

24
Clocks in C and POSIX

• There are standard libraries for interfacing with
  calendar time
• The resolution should be at least 20 ms
• It is possible to determine the resolution on the
  current system, i.e. the call clock_getres will
  tell you what each tick means

25
Delaying a process

• There are two ways of delaying a process
• Relative delays, e.g. delay 10.0 (this is Ada,
  and it means block the current process 10 s). The
  time is lower limit the actual delay could be
  longer due to overhead, scheduling and blocked
  interrupts.
• Absolute delays, e.g. delay until
  next_period(this is again Ada and it means that
  the process should be delayed until the clock is
  equal to next_period). Again, the actual delay
  could be longer due to overhead, scheduling and
  blocked interrupts.

26
Timeouts

• A timeout is a restriction on the time a process
  is prepared to wait for a communication
• Ada example relative delay
• task body controller isNew_Temp Temperature
• begin
• loop
• select
• accept Call(T Temeperature) do
• New_Temp T
• end Call
• or
• delay 10.0
• -- actions for timeout
• end select
• end loop
• end controller

27
Ada example absolute delay

• Task body ticket_agent is
• -- declarations
• shop_open boolean true
• begin
• while shop_open loop
• select
• accept Registration() do
• -- log details
• end Registration
• or
• delay until closing_time
• shop_open false
• end select
• -- process registrations
• end loop
• end ticket_agent

28
Ada example timed and conditional entry calls

• select -- conditional entry call
• T.E -- entry E in task T
• else
• -- other actions
• end select
• select -- timed entry call
• P.E -- entry E in protected object P
• or
• delay 0.5
• End select

29
Ada example time out on actions

• select -- An action that must be completed within
  100 ms
• delay 0.1
• then abort
• -- action
• end select

30
Ada example imprecise computations

• declare
• precise_result boolean true
• begin
• completion_time
• -- calculate rough value
• write_result() -- write imprecise value
• select
• delay until completion_time
• precise_result false
• then abort
• while can_be_improved loop
• -- improve result
• write_result() -- save improved value
• end loop
• end select
• end