# INSE - Lectures 19 & 20 SE for Real-Time & SE for Concurrency  Really these are two topics – but rather tangled together.

## Presentation on theme: "INSE - Lectures 19 & 20 SE for Real-Time & SE for Concurrency  Really these are two topics – but rather tangled together."— Presentation transcript:

INSE - Lectures 19 & 20 SE for Real-Time & SE for Concurrency  Really these are two topics – but rather tangled together

Double-lecture structure  Real-time – concepts  Real-time – system characteristics  Concurrency – concepts  Concurrency – processes  Real-time scheduling of concurrency

Real-Time - Concepts

“ Real-time system ”  Some computer systems have to do certain outputs before particular actual times  they have to “ meet deadlines ”

Forms of deadline  fixed lead time after some stimulus event; or  variable lead time (from a stimulus) before some outside world event happens; or  clocked deadlines (usually at regular outside-world intervals); or  continuous (e.g. keeping something up- to-date)

Kinds of Stimuli One classification:  periodic – e.g. “ will come between 4 and 6 seconds after the last one ”  uniform – e.g. “ averaging 10 per minute ” = probability of 1 / 6 th in any second  sporadic – a burst of stimuli, then a lull

Severity of deadlines  The consequences of missing a deadline vary from systems to system  or even between different sorts of deadline in a single system  Common classifications:  hard – missing the deadline is some sort of catastrophe  soft – missing the deadline is embarrassing or irritating  optimum – we want to minimize the average response time

Challenge: meeting deadlines  How long will a “ task ” take?  Will/can it complete between stimulus and deadline?  Should concurrent tasks  run “ in parallel ” ? or  run one at a time “ to completion ” ?  when should each task be started?

Challenge: how much memory?  Peak memory demand?  is there enough RAM?  Preventing “ memory leakage ”

Challenge: testing  How to generate test stimuli?  How to test for having met a deadline?  How to test for memory issues?  How to test without perturbation – i.e. without the test mechanism affecting speed or size

Challenge: Human issues  How to find staff who can visualize the timing issues?

Real-Time System Characteristics

Real-time systems are often also …  safety-critical or security-critical;  embedded (including control systems)

Real time system size … … varies enormously:  from tiny embedded systems (e.g. in a washing machine)  to the world-wide “ cashcard ” system

Real-time system “ modes ”  Many real-time systems have a number of “ modes ” – and will be in one at a time.  E.g. for a washing machine:  idle;  washing;  rinsing;  draining;  spinning.

Clashing deadlines  Suppose another stimulus comes in while the task for another kind of stimulus is processing  should the new task wait for the other to end?  should the two tasks run “ simultaneously ” ?  I.e. “ queued ” or “ concurrent ” ?

Priority of a deadline  A concurrent deadline might have a priority  will depend on how soon the deadline it is, how severe the deadline is, etc;  used in deciding which deadline ’ s process gets the CPU  Mode-change => change of priority?

Jitter vs stability  A system might be prone to timing races between tasks  may cause long-term behaviour changes – jitter  otherwise the system is stable

Concurrency – Concepts

A non-concurrent program …  … is a sequence of instruction ( “ the code ” ), and  a set of data.  There is a single continuous “ thread of control ” through the instructions.

Two generalizations: 1) non-continuous; 2) more than one “ thread of control ”  These lead to two different forms of concurrency  (but we can also have the two forms together)

Non-continuous programming  The program runs to complete a “ task ”, which then sleeps or dies;  Later the program re-awakens, and runs another task.  The program consists of code for the various tasks –  the tasks might run in any order;  the tasks usually share their data.

Interrupt-driven programming  Non-continuous programming where the tasks are started by interrupts  the interrupts may be hardware- generated;  the interrupts may be user- generated.

Uses of i/r-driven programming include …  inside an Operating System for the various OS processes  controlled by a scheduler in the OS ’ s kernel  in embedded systems  (kernel without full OS)  in GUI programming for user events.

Concurrency (=parallelism) = multiple continuous “ threads of control ” (possibly scattered across >1 CPU)

Hybrids 1) Multiple non-continuous tasks at the same time 2) Continuous threads and also non- continuous tasks at the same time

Concurrency – processes Process =  a concurrent thread of control  the code it executes though  the data it operates on

States of a process … … typically include  running – the/a CPU is executing the process ’ s thread of control  ready – it could run, but hasn ’ t currently been scheduled  blocked – it has done something that stops it running for now  suspended – another process has stopped it

Inter-process communication When processes share resources  they need to collaborate  not conflict.

An example of conflict (1)  Suppose 2 processes share an integer variable V, & both try to add one to it …  Initially the variable contains (say) 27 … V=27

An example of conflict (2)  Suppose 2 processes share an integer variable V, & both try to add one to it … .. then process A takes a copy of V ’ s value … V=27 A ’ s copy = 27

An example of conflict (3)  Suppose 2 processes share an integer variable V, & both try to add one to it … .. then process B takes a copy of V ’ s value … V=27 A ’ s copy = 27 B ’ s copy = 27

An example of conflict (4)  Suppose 2 processes share an integer variable V, & both try to add one to it … .. then process A adds one to it ’ s copy of V ’ s value … V=27 A ’ s copy = 28 B ’ s copy = 27

An example of conflict (5)  Suppose 2 processes share an integer variable V, & both try to add one to it … .. then process B adds one to it ’ s copy of V ’ s value … V=27 A ’ s copy = 28 B ’ s copy = 28

An example of conflict (6)  Suppose 2 processes share an integer variable V, & both try to add one to it … .. then process A writes it ’ s copy back to V itself … V=28 A ’ s copy = 28 B ’ s copy = 28

An example of conflict (7)  Suppose 2 processes share an integer variable V, & both try to add one to it … .. then process B also writes it ’ s copy back to V itself … V=28 (still) A ’ s copy = 28 B ’ s copy = 28

An example of conflict (8)  Suppose 2 processes share an integer variable V, & both try to add one to it … .. we have added one to 27, twice … V=28 and the result is 28, not 29!!!

Preventing conflict (1)  Put each of the “ add-one ” instructions into a mutual exclusion zone: wait till V is unlocked, then lock it V = V+1 unlock V

Preventing conflict (2)  Implementing that wait+lock/ unlock capability needs either interrupts off or that the wait+lock and unlock operations be operating system calls

Cooperation  So the “ mutual exclusion ” technique will give us co-operation rather than conflict  But mutual exclusion can lead to “ deadly embrace ”  avoiding that calls for careful design, rather than indiscriminate use of mutual exclusion

Challenge: Human issues  How to find staff who can visualize the conflict/coperation/deadly embrace issues?

Real-Time scheduling of Concurrency  If a system is both real-time and concurrent then  concurrent => we need scheduling  real-time => the scheduling needs to enable meeting deadlines

Techniques of r/t scheduling  Very dependant on the application  The notes describe assorted detailed techniques

After this double lecture  There are a lot of real-time jobs out there  are you right for them?