80

Characteristics of RTS
Large and complex Concurrent control of separate system components Facilities to interact with special purpose hardware. Guaranteed response times Extreme reliability Efficient implementation

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

81

Concurrent Programming
The name given to programming notation and techniques for expressing potential parallelism and solving the resulting synchronisation and communication problems Implementation of parallelism is a topic in computer systems (hardware and software) that is essentially independent of concurrent programming Concurrent programming is important because it provides an abstract setting in which to study parallelism without getting bogged down in the implementation details
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

82

Why we need it
To fully utilise the processor

Response time in seconds

10

2 1

10 0 10 -1 10 10 -3 10 -4 10 10 10 10 10 10
-5 -6 -7 -8 -9 -2

human

tape floppy CD

memory processor
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

83

Parallelism Between CPU and I/O Devices

CPU Initiate I/O Operation I/O Device

Process I/O Request

Signal Completion Interrupt I/O Routine I/O Finished Continue with Outstanding Requests
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

84

Why we need it
To allow the expression of potential parallelism so that more than one computer can be used to solve the problem Consider trying to find the way through a maze

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

85

Sequential Maze Search

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

86

Concurrent Maze Search

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

87

Why we need it
To model the parallelism in the real world Virtually all real-time systems are inherently concurrent devices operate in parallel in the real world This is, perhaps, the main reason to use concurrency

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

88

Why we need it
The alternative is to use sequential programming techniques The programmer must construct the system so that it involves the cyclic execution of a program sequence to handle the various concurrent activities This complicates the programmer's already difficult task and involves him/her in considerations of structures which are irrelevant to the control of the activities in hand The resulting programs will be more obscure and inelegant It makes decomposition of the problem more complex Parallel execution of the program on more than one processor will be much more difficult to achieve The placement of code to deal with faults is more problematic
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

89

Terminology
A concurrent program is a collection of autonomous sequential processes, executing (logically) in parallel Each process has a single thread of control The actual implementation (i.e. execution) of a collection of processes usually takes one of three forms. Multiprogramming
processes multiplex their executions on a single processor

Multiprocessing
processes multiplex their executions on a multiprocessor system where there is access to shared memory

Distributed Processing
processes multiplex their executions on several processors which do not share memory
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

90

Process States
Non-existing Non-existing

Created

Initialising

Terminated

Executable

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

91

Run-Time Support System

An RTSS has many of the properties of the scheduler in an operating system, and sits logically between the hardware and the application software. In reality it may take one of a number of forms:
A software structure programmed as part of the application. A standard software system generated with the program object code by the compiler. A hardware structure micro-coded into the processor for efficiency.

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

92

Processes and Threads

All operating systems provide processes Processes execute in their own virtual machine (VM) to avoid interference from other processes Recent OSs provide mechanisms for creating threads within the same virtual machine; threads are sometimes provided transparently to the OS Threads have unrestricted access to their VM The programmer and the language must provide the protection from interference Long debate over whether language should define concurrency or leave it up to the OS

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

93

Concurrent Programming Constructs

Allow The expression of concurrent execution through the notion of process Process synchronisation Inter-process communication. Processes may be independent cooperating competing

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

94

Concurrent Execution
Processes differ in Structure static, dynamic Level nested, flat Granularity coarse, fine Initialisation parameter passing, IPC Termination
completion of execution of the process body; suicide, by execution of a self-terminate statement; abortion, through the explicit action of another process; occurrence of an untrapped error condition; never: processes are assumed to be non-terminating loops; when no longer needed.
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

95

Nested Processes
Hierarchies of processes can be created and interprocess relationships formed For any process a distinction can be made between the process (or block) that created it and the process (or block) which is affected by its termination The former relationship is known as parent/child and has the attribute that the parent may be delayed while the child is being created and initialised The latter relationship is termed guardian/dependent. A process may be dependent on the guardian process itself or on an inner block of the guardian The guardian is not allowed to exit from a block until all dependent processes of that block have terminated
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

96

Nested Processes
A guardian cannot terminate until all of its dependents have terminated A program cannot terminate until all of its processes have terminated A parent of a process may also be its guardian (e.g. with languages that allow only static process structures) With dynamic nested process structures, the parent and the guardian may or may not be identical

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

97

Process States
Non-existing Non-existing

Created

Initialising

Terminated

Waiting Child Initialisation

Executable

Waiting Dependent Termination

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

98

Processes and Objects

Active objects undertake spontaneous actions Reactive objects only perform actions when invoked Resources reactive but can control order of actions Passive reactive, but no control over order Protected resource passive resource controller Server active resource controller

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

99

Process Representation
Co-routines Fork and Join Co-begin Explicit Process Declaration

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

100

Co-routine Flow Control

Co-routine A 1 6 resume B 7 resume B 11 12 resume c
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

Co-routine B 2 4

Co-routine C 5 resume A 6

3 resume C

13 14 resume B

12

9 resume A 15

10

101

Note
No return statement only a resume statement The value of the data local to the co-routine persist between successive calls The execution of a co-routine is suspended as control leaves it, only to carry on where it left off when it resumed

Do co-routines express true parallelism?

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

102

Fork and Join

The fork specifies that a designated routine should start executing concurrently with the invoker Join allows the invoker to wait for the completion of the invoked routine
function F return is ...; procedure P; ... C:= fork F; ... J:= join C; ... end P;

After the fork, P and F will be executing concurrently. At the point of the join, P will wait until the F has finished (if it has not already done so)
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

103

UNIX Fork Example

for (I=0; I!=10; I++) { pid[I] = fork(); } wait . . .

How many processes created?

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

104

Cobegin
The co-begin (or parbegin or par) is a structured way of denoting the concurrent execution of a collection of statements:
cobegin S1; S2; S3; . . Sn coend

S1, S2 etc, execute concurrently The statement terminates when S1, S2 etc have terminated Each Si may be any statement allowed within the language
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

105

Explicit Process Declaration

The structure of a program can be made clearer if routines state whether they will be executed concurrently Note that this does not say when they will execute
task body Process is begin . . . end;

Languages that support explicit process declaration may have explicit or implicit process/task creation
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

106

A Simple Embedded System

Thermocouples ADC Pressure Transducer

T Switch Heater S P ADC

Screen

DAC

Pump/Valve

Overall objective is to keep the temperature and pressure of some chemical process within well-defined limits
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

107

Possible Software Architectures

A single program is used which ignores the logical concurrency of T, P and S; no operating system support is required T, P and S are written in a sequential programming language (either as separate programs or distinct procedures in the same program) and operating system primitives are used for program/process creation and interaction A single concurrent program is used which retains the logical structure of T, P and S; no operating system support is required although a run-time support system is needed Which is the best approach?
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

108

Disadvantages of the Sequential Solution

Temperature and pressure readings must be taken at the same rate While waiting to read a temperature no attention can be given to pressure (and vice versa) Moreover, a system failure that results in, say, control never returning from the temperature Read, then in addition to this problem no further calls to Read the pressure would be taken The major criticism with the sequential program is that no recognition is given to the fact that the pressure and temperature cycles are entirely independent subsystems. In a concurrent programming environment this can be rectified by coding each system as a task.
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

109

Advantages of Concurrent Approach

Controller tasks execute concurrently and each contains an indefinite loop within which the control cycle is defined While one task is suspended waiting for a read the other may be executing; if they are both suspended a busy loop is not executed The logic of the application is reflected in the code; the inherent parallelism of the domain is represented by concurrently executing tasks in the program

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

110

Disadvantages
Both tasks send data to the screen, but the screen is a resource that can only sensibly be accessed by one process at a time A third entity is required. This has transposed the problem from that of concurrent access to a nonconcurrent resource to one of resource control It is necessary for controller tasks to pass data to the screen resource The screen must ensure mutual exclusion The whole approach requires a run-time support system

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

111

OS versus Language Concurrency

Should concurrency be in a language or in the OS? Arguments for concurrency in the languages:
It leads to more readable and maintainable programs There are many different types of OSs; the language approach makes the program more portable An embedded computer may not have any resident OS

Arguments against concurrency in a language:

It is easier to compose programs from different languages if they all use the same OS model It may be difficult to implement a language's model of concurrency efficiently on top of an OS model OS standards are beginning to emerge

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

112

Summary of Concurrent Programming

The application domains of most real-time systems are inherently parallel The inclusion of the notion of process within a real-time programming language makes an enormous difference to the expressive power and ease of use of the language Without concurrency the software must be constructed as a single control loop The structure of this loop cannot retain the logical distinction between systems components. It is particularly difficult to give process-oriented timing and reliability requirements without the notion of a process being visible in the code
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

113

Summary
The use of a concurrent programming language is not without its costs. In particular, it becomes necessary to use a run-time support system to manage the execution of the system processes The behaviour of a process is best described in terms of states
non-existing created initialised executable waiting dependent termination waiting child initialisation terminated

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

114

Variations in the Process Model

structure
static, dynamic

level
top level processes only (flat) multilevel (nested)

initialization
with or without parameter passing

granularity
fine or coarse grain

termination
natural, suicide abortion, untrapped error never, when no longer needed

representation
Slides Alan Burns and Andy Wellings, 2001 Co-routines, fork/join, cobegin, explicit processOriginal declarations Modified - CLR-Jan 2002, Sep 2005.

115

Characteristics of a RTS
Large and complex Concurrent control of separate system components Facilities to interact with special purpose hardware Guaranteed response times Extreme reliability Efficient implementation

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

116

Hardware Input/Output Mechanisms

Two general classes of computer architecture: Separate Buses for Devices and Memory Data Data

Memory

CPU

Devices

Devices

Address Address

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

117

Memory Mapped Architecture

Data

CPU

Memory

Devices

Devices

Address

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

118

Device Interface
The interface to a device is normally through a set of registers Separate buses: two sets of assembly instructions one for memory access the other for device register access The latter normally take the form of: IN AC, PORT OUT AC, PORT E.g., the Intel 486 and Pentium range Memory-mapped I/O: certain addresses access memory others the device registers; e.g., M68000 and PowerPC ranges The interface is used to control the devices operations and to control the data transfer Two control mechanisms: status driven and interrupt driven control
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

119

Status Driven
A program performs explicit tests in order to determine the status of a given device Three kinds of hardware instructions:
test operations that enable the program to determine the status of the given device control operations that direct the device to perform non-transfer device dependent actions such as positioning read heads I/O operations that perform the actual transfer of data between the device and the CPU

Nowadays most devices are interrupt driven. Interrupts can of course be turned off and polling of device status used instead. Interrupts are often not allowed in Safety Critical Systems
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

120

Interrupt Driven
Interrupt-driven program-controlled Interrupt-driven program-initiated (DMA) Interrupt-driven channel-program controlled

DMA and channel programs can cause cycle stealing from the processor; this may make it difficult to estimate the worst-case execution time of a process

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

121

Elements Needed for Interrupt Driven Devices

1 Context switching mechanisms

Preserving the state (PC, registers, program status info priority, memory protection etc.) of the processor immediately prior to the occurrence of the interrupt. Placing the processor in the required state for processing the interrupt. Restoring the suspended process state after the interrupt processing has been completed. basic: just the PC is saved; partial: PC and the PSW are saved; complete: full context is saved.

It may be necessary to supplement the actions of the hardware by explicit software support
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

122

Elements Needed
2 Interrupting device identification
A vectored mechanism consists of a set of dedicated, contiguous memory locations (an interrupt vector) and a hardware mapping of device addresses onto the interrupt vector With a status mechanism, each interrupt has an associated status word which specifies the device causing the interrupt and the reason for the interrupt The polling device identification mechanism involves interrogating the status of each device

With some modern computer architectures, interrupt handling is directly associated with a high-level language primitive With these systems, an interrupt is often viewed as a synchronisation message down an associated channel; the device is identified by the channel which becomes active
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

123

Elements Needed
3 Interrupt identification Once the device has been identified, the appropriate interrupt handling routine must determine why it generated the interrupt This can be supplied by either status information provided by the device or by having different interrupts from the same device occurring through different vectored locations or channels

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

124

Elements Needed
4 Interrupt control Once a device is switched on its interrupts must be enabled. Enabling/disabling of interrupts may be performed by:
Status mechanisms provide flags to enable/disable interrupts. Mask interrupt control mechanisms associate device interrupts with particular locations in an interrupt mask word Level-interrupt control mechanisms have devices associated with certain levels; the current level of the processor determines which devices may or may not interrupt

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

125

Elements Needed
5 Priority control Some devices have higher urgency than others and, therefore, a priority facility is often associated with interrupts This mechanism may be static or dynamic and is usually related to the device interrupt control facility and the priority levels of the processor

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

126

A Simple Example I/O System

Loosely based on the Motorola 68000 series of computers; the registers are memory mapped Control & status registers contain all the information on a devices status, and allow the devices interrupts to be enabled / disabled.
bits 15 - 12 11 10 - 8 7 6 5-3 2-1 0 : Errors : Busy : Unit select : Done/ready : Interrupt enable : reserved : Device function : Device enable
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

127

A Simple Example I/O System

Data buffer registers act as buffer registers for temporarily storing data to be transferred into or out of the machine via the device
15 - 8 7-0 : Unused : Data

A device may have more than one csr and dbr, the exact number being dependent on the nature of the device. On an interrupt, the processor stores the PC and the current program status word (PSW) on the system stack The new PC and PSW are loaded from an interrupt vector The first word contains the address of the interrupt service routine and the second contains the PSW including the priority at which the interrupt is to be handled
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

128

Language Requirements
Modularity & encapsulation facilities
Device interfacing is machine dependent. It is important to separate the non-portable sections of code from the portable ones.

An abstract model of device handling

A device can be viewed as a processor performing a fixed task. A computer system can be modelled as several parallel processes which need to communicate and synchronise; synchronisation is provided by the interrupt

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

129

Abstract Models
All models require facilities for addressing and manipulating device registers
A device register may be represented as a program variable, an object, or even a communications channel

A suitable representation of an interrupt:

procedure call sporadic process invocation asynchronous notification shared-memory based condition synchronisation message-based synchronisation

All except procedure, view the handler as executing in the scope of a process, and therefore require a full context switch
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

130

Addressing/Manipulating Device Registers

Associating a variable with a register is expressed by an octal address following the name in a declaration. E.g. a data buffer register for the simple I/O architecture
VAR rdbr[177562B] CHAR; 177562B is an octal address which is the location of the register in memory

Only scalar data types can be mapped onto a device register; registers which have internal structures are considered to be of the predefined type bits whose definition is:
type bits = array 0:no_of_bits_in_word OF BOOLEAN;

Variables of this type are packed into a single word

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

131

Addressing/Manipulating Device Registers

A control and status register at octal address 177560 can therefore be defined by:
VAR rcsr[177560B] : BITS;

The following will enable the device and turn interrupts off
rcsr[0] := TRUE; rcsr[6] :=False;

In general these facilities are not powerful enough to handle all types of registers conveniently; consider setting 10 - 8 : Unit select to the value 5
rcsr[10] := true; rcsr[9] := false; rcsr[8] := true;

Clumsy

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

132

Note
On many machines more than one device register can be mapped to the same physical address; these registers are often read or write only Care must be taken when manipulating device registers. If the CSR was a pair of registers mapped to the same location, the code will not have the desired affect. WHY? It is advisable to have other variables in a program which represent device registers; these can be manipulated in the normal way When the required register format has been constructed it may then be assigned to the actual device register Such variables are often called shadow device registers
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.