dedicated systems experts 2005 - martin timmerman p. 1 rtos: the state of the art module 3...

Dedicated Systems Experts 2005 - Martin TIMMERMAN p. 1

RTOS: the state of the art

Module 3Synchronisation and

Communication

Dedicated Systems Experts – 2005 – Martin TIMMERMAN p. 2

Synchronisation and Communication

• In non RT applications: Minimal or NO synchronisation of communication.

• In RT applications: Maximum synchronisation & communication.


Content of module 3

a. Mutual exclusion & Synchronization b. Serializationc. High Level Mechanismsd. Deadlock and Indefinite

Postponemente. Good RTOS requirmentsf. Case studyg. Application hintsh. Conclusions


M3a: Mutual exclusion


MUTUAL EXCLUSION

• Background• Producer-consumer problem &

solutions• Semaphores• Event flag & Event flag group• Block & Wakeup• Event Counts & Sequencers


MUTEX: Background• producer-consumer examples

– print program toward printer driver– compiler - assembler– assembler - loader

• the problem– unbounded buffer– bounded buffer

(= fixed size buffer)

• producer and consumer may run on different processors!

C sourceCode

Pre-processorProcess

Buffer forPre-processed

Source

Shared MemoryPipe

CompilerProcess

ObjectCode


Producer-consumer solution 1

var n;type item = ... ;var buffer: array [0..n-1] of item;in, out: 0..n-1;

var n;type item = ... ;var buffer: array [0..n-1] of item;in, out: 0..n-1;

repeat...produce an item in nextp...while in+1 mod n = out do no-op;buffer [in] := nextp;in := in+1 mod n;

until false;

repeat...produce an item in nextp...while in+1 mod n = out do no-op;buffer [in] := nextp;in := in+1 mod n;

until false;

Producer

repeatwhile in = out do no-op;nextc := buffer[out];out:= out + 1 mod n;...consume the item in nextc...

until false;

repeatwhile in = out do no-op;nextc := buffer[out];out:= out + 1 mod n;...consume the item in nextc...

until false;

Consumer

Only n-1 buffers are full at the same time.

Shared variables

Microsoft PowerPoint Presentation

Animation:


Producer-consumer solution 2

var n, counter;type item = ... ;var buffer: array [0..n-1] of item;in, out: 0..n-1;

var n, counter;type item = ... ;var buffer: array [0..n-1] of item;in, out: 0..n-1;

repeat...produce an item in nextp...while counter = n do no-op;buffer [in] := nextp;in := in+1 mod n;counter := counter + 1;

until false;

repeat...produce an item in nextp...while counter = n do no-op;buffer [in] := nextp;in := in+1 mod n;counter := counter + 1;

until false;

repeatwhile counter = 0 do no-op;nextc := buffer[out];out:= out + 1 mod n;counter = counter - 1;...consume the item in nextc...

until false;

repeatwhile counter = 0 do no-op;nextc := buffer[out];out:= out + 1 mod n;counter = counter - 1;...consume the item in nextc...

until false;

Producer

Consumer

Shared variables


Animation:


counter := counter + 1

register1 := counter;register1 := register1 + 1;counter := register1

counter := counter - 1

register2 :=counter;register2 := register2 - 1;counter := register2

register1 := counter;register1 := register1 + 1;

counter := register1

...........

register2 :=counter;register2 := register2 - 1;


register1 := counter;register1 := register1 + 1;

register2 :=counter;register2 := register2 - 1;



The previous routines may not function correctly!

Race condition!!


The Critical-Section Problem

• execution of critical section is mutual exclusive in time:if one process is executing in its critical section, no other process is allowed to execute in its critical section

• The purpose: design a protocol for cooperation

• request permission to use critical section: entry section

• exit section


Critical-section problem: requirements

• R1: Mutual Exclusion:– only 1 process may execute his critical-section

• R2: Progress: no indefinitely postponement

– only processes not executing in their remainder section should participate in the decision which one is going to enter his critical section

• R3: Bounded waiting: do not wait forever for others P

– bound to the # of times a P should enter his critical section before other P’s do.

• Assumptions– a process is executing at non zero speed– relative speed of n processes may be the same or very

different– each machine instruction is indivisibly: atomic instructions


repeat

entry section

critical section

exit section

remainder section

until false;

repeat

entry section

critical section

exit section

remainder section

until false;

Process general structure

Assembly instructions such as load, store, test are executed atomically.


Solutions

• Software solutions– two process solution– multiple process solution

• Hardware solutions


P0P0

repeat

while turn <> 0 do no-op;

critical section

turn := 1

remainder section

until false;

repeat


critical section

turn := 1

remainder section

until false;

P1P1

Try 1 for 2 process solutions: a1

repeat


critical section

turn := 0

remainder section

until false;

repeat


critical section

turn := 0

remainder section

until false;

Only one process can be in its critical section at the same time. R1: OK - R2: NOK: Pi should alternate before it works!No process state kept – see solution a2.

shared variable: var turn: integer


P0P0

Try 2 for 2 process solutions: a2

repeat

flag[0] := true;while flag[1] do no-op;

critical section

flag[0] := false;

remainder section

until false;

repeat


critical section

flag[0] := false;

remainder section

until false;

P1P1

repeat


critical section

flag[1] := false;

remainder section

until false;

repeat


critical section

flag[1] := false;

remainder section

until false;

R1: OK - R2: NOK: time critical

if context switch: problem

shared variable: var flag: array [0..1] of boolean


P0P0 P1P1

Try 3 for 2 process solutions: a3Peterson 1981

repeat

flag[0] := true;turn := 1;while (flag[1] and turn=1)

do no-op;

critical section

flag[0] := false

remainder section

until false;

repeat


do no-op;

critical section

flag[0] := false

remainder section

until false;

repeat


do no-op;

critical section

flag[1] := false

remainder section

until false;

repeat


do no-op;

critical section

flag[1] := false

remainder section

until false;

R1: OK - R2: OK - R3: OK

shared variables: var flag: array [0..1] of boolean var turn: integer


N-process solutions

• pro memory• Called bakery algorithm

(each customer in a store receives a number….)


Synchronization hardware

• Mask interruptspossible in uni-processor systems - no solution in RT!!

• Test-and-Set (TAS)

• Swap

function TAS (var target: boolean): boolean;begin

Test-and-Set := target;target := true;

end;

function TAS (var target: boolean): boolean;begin

Test-and-Set := target;target := true;

end;

procedure swap (var a,b: boolean);var temp: boolean;begin

temp:= a;a := b;b := temp;

end;

procedure swap (var a,b: boolean);var temp: boolean;begin

temp:= a;a := b;b := temp;

end;


Examples/remarks• http://en.wikipedia.org/wiki/Test-and-set• http://en.wikipedia.org/wiki/Compare-and-swap

• X86: BTS• 68000: TAS• ….

• Take care: should also be executed in an atomic way on a bus if any!!


P1P1 P2P2

repeat

while TAS (lock) do no-op;

critical section

lock := false

remainder section

until false;

repeat


critical section

lock := false

remainder section

until false;

repeat


critical section

lock := false

remainder section

until false;

repeat


critical section

lock := false

remainder section

until false;

R1: OK - R2: OK - R3: NOK!!

Try 1 using TAS


P0P0 P1P1

Try 1 using SWAP (pm)

repeat

key0 := true;repeat

swap(lock,key0) ;until key0 = false

critical section

lock := false

remainder section

until false;

repeat

key0 := true;repeat


critical section

lock := false

remainder section

until false;

repeat

key1 := true;repeat


critical section

lock := false

remainder section

until false;

repeat

key1 := true;repeat


critical section

lock := false

remainder section

until false;

R1: OK - R2: OK - R3: NOK!!


Semaphores

• Introduction• Usage• Implementation


S: intro - definition

• previous solutions:– cannot be generalized to complex

problems

• S : integer variable accessed via 2 atomic operations

wait(S): while S =< 0 do no-op;S := S - 1;

signal(S): S := S + 1;

P - operation proberen

V - operation verhogen


S: usage 1: n-process critical section

problem

repeat

wait (sema);

critical section

signal (sema);

remainder section

until false;

P4

repeat

wait (sema);

critical section

signal (sema);

remainder section

until false;

P3

repeat

wait (sema);

critical section

signal (sema);

remainder section

until false;

P2

repeat

wait (mutex);

critical section

signal (mutex);

remainder section

until false;

P1


S: usage 2: synchronization

.

.

.

.S1signal(SF)...

Process 1Process 1

.

.wait (SF)S2.....

Process 2Process 2

P1

P2

S1

S2

time


S: BUSY WAITING problem

wait(S): while S =< 0 do no-op;S := S - 1;

signal(S): S := S + 1;

P - operation proberen

V - operation verhogen

BUSY WAITING


S: implementation

type semaphore = recordvalue: integer;L: list of process;

end

type semaphore = recordvalue: integer;L: list of process;

end

wait (S): S.value := S.value - 1;if S.value < 0

then beginadd this process to S.L;block;

end;signal(S): S.value := S.value + 1;

if S.value =< 0then begin

remove a process fromS.L;wakeup(P);

end;

wait (S): S.value := S.value - 1;if S.value < 0

then beginadd this process to S.L;block;

end;signal(S): S.value := S.value + 1;

if S.value =< 0then begin

remove a process fromS.L;wakeup(P);

end;

Running

Ready Blocked

Block

Timerrunout

Dispatch

Wakeup


Semaphore example

prio: 100prio: 100 prio: 150prio: 150 prio: 160prio: 160

create SF...wait (SF)

.critical code.

signal(SF)

Task A: draw backgroundTask A: draw background

wait i/o..wait (SF)

.critical code.

signal(SF).

Task B: measure & colourTask B: measure & colour

.wait i/o

.wait (SF)

.critical code.

signal(SF).

Task C: measure & indicateTask C: measure & indicate

SF S-List Screen Memory

waiting task priority


Animation:


Priority inversion handling

• Not needed IF good design• But we are only human so you better

have priority inheritance


prio: 120prio: 120

Priority inversion

.

.wait i/o

.

.

.compute an hour

.

.

.

.

Task D: very urgentTask D: very urgent

prio: 100prio: 100 prio: 150prio: 150 prio: 160prio: 160


.critical code.

signal(SF)


wait i/o..wait (SF)

.critical code.

signal(SF).


.wait i/o

.wait (SF)

.critical code.

signal(SF).





Animation:


prio: 100prio: 100 prio: prio: prio: 120prio: 120

Priority inheritance

.

.wait i/o

.

.

. compute an hour

.

.

.

.


prio: 150prio: 150 prio: 160prio: 160


.critical code.

signal(SF)


wait i/o..wait (SF)

.critical code.

signal(SF).


.wait i/o

.wait (SF)

.critical code.

signal(SF).




Animation:Microsoft

PowerPoint Presentation


prio: 100prio: 100 prio: prio: prio: 120prio: 120

Priority ceiling

.

.wait i/o

.

.

. compute an hour

.

.

.

.


prio: 150prio: 150 prio: 160prio: 160


.critical code.

signal(SF)


wait i/o..wait (SF)

.critical code.

signal(SF).


.wait i/o

.wait (SF)

.critical code.

signal(SF).




Animation:Microsoft

PowerPoint Presentation


Other synch primitives

• if you have one synch primitive(a semaphore for example), you can create all the other ones

• Where should this be implemented– In the application?– In the OS?– In a special RT language (ex.: ADA..)


Event Flags

set EvtFlg

Task STask S

EvtFlgEvtFlg

wait EvtFlg

Task R1Task R1

wait EvtFlg

reset EvtFlg

Task R2Task R2


set EvtFlgGr1

Event Flag Groups

wait EvtFlgGr1OREvtFlgGr3

Task R1Task R11

1

22

33

44

EvtFlgGrEvtFlgGr

wait EvtFlgGr1ANDEvtFlgGr3

Task R2Task R2

Task S1Task S1

set EvtFlgGr3

Task S2Task S2


Block & Wakeup

• Problems with semaphores– number is unknown so space to be

needed is also unknown– this gives problems during system

generation

• Block & Wakeup: need one bit– one bit per process– maximum number of processes know in

advance


Block & Wakeup• B-primitive

– stops process that invokes B – put the process on a waiting list– one variable per process:

Wakeup-Waiting Switch (WWS)

• W-primitive– takes one argument: name of process to

wakeup

• WWS– needed if WAKEUP comes before BLOCK– may be a counter

• ! you need to know the name of the P’s


P1P1 P2P2

Block & Wakeup

repeat

produce(MESSAGE,B)

WAKEUP(P2)

BLOCK()

until false;

repeat

produce(MESSAGE,B)

WAKEUP(P2)

BLOCK()

until false;

repeat

BLOCK()

consume(MESSAGE,B)

WAKEUP(P1)

until false;

repeat

BLOCK()

consume(MESSAGE,B)

WAKEUP(P1)

until false;


Event Counts & Sequencers

• idea: bakery solution (with tickets)• a sequencer T (counter)

• an event count E (counter)

• Operations– TICKET(T)– AWAIT(E,N)– ADVANCE(E)– READ(E)

TICKET (T): T = T + 1Return(T)

AWAIT(E,N): IF E = N THEN RETURNELSE WAIT (E = N)

ADVANCE(E): E = E + 1START (PROCESSOR WAITING FOR E= N)

READ(E): RETURN(E)


Event Counts & Sequencers

• advantages– T forces strict sequencing– no mutual exclusion between AWAIT and

ADVANCE– no need for shared memory

communication– potential for distributed systems

• drawback– starvation if one processor crashes


Classical problems of synchronization

• The bounded-buffer problem• The readers and writers problem• The dining-philosophers problem


The bounded-buffer problem• buffer pool of n buffers• mutex:

– semaphore for mutual exclusion for accesses to the buffer pool

– initial value: 1

• empty: (counting semaphore)– counts the number of empty buffers– initial value: n

• full: (counting semaphore)– counts the number of full buffers– initial value: n


The bounded-buffer problem

repeat...produce an item in nextp...wait(empty);wait(mutex);...add nextp to buffer...signal(mutex);signal(full);

until false;

repeat...produce an item in nextp...wait(empty);wait(mutex);...add nextp to buffer...signal(mutex);signal(full);

until false;

ProducerProducer

repeatwait(full);wait(mutex);...remove item from buffer

to nextc...signal(mutex);signal(full);...consume the item in nextc...

until false;

repeatwait(full);wait(mutex);...remove item from buffer

to nextc...signal(mutex);signal(full);...consume the item in nextc...

until false;

ConsumerConsumer


P2

Pn

P1Full SF

number of msg in queue

Empty SFnumber of slots in queue

C2

Cm

C1

BufferQueue

Mutex

The bounded-buffer problem


The Readers & Writers Problem

• share a file or record between P’s• when all P’s are readers - no problem• if one writer then ......

– writers need exclusive access to shared resource


The Dining-Philosophers Problem


M3b: Serialisation


SERIALIZATION• Banker’s problem

• 2 phase locking

Account 1 Account 2P1

transfer

P2make sum


M3c: High Level Mechanisms


HIGH LEVEL MECHANISMS

• convenience• critical regions• conditional critical regions• monitors• path expressions• message passing• distributed systems


HLM: Convenience

• problems with semaphores:– timing errors that are difficult to detect– occur when particular execution

sequences happen

• programming errors:

signal(mutex);.....critical section....

wait(mutex);

signal(mutex);.....critical section....

wait(mutex);

wait(mutex);.....critical section....

wait(mutex);

wait(mutex);.....critical section....

wait(mutex);

.....critical section....

.....critical section....


P1P1 P2P2

HLM: critical regions

declare B shared

repeat..produce(MESSAGE,B)...

until false;

declare B shared

repeat..produce(MESSAGE,B)...

until false;

declare B shared

repeat..consume(MESSAGE,B)...

until false;

declare B shared

repeat..consume(MESSAGE,B)...

until false;


P1P1 P2P2

HLM: conditional critical regions

declare B sharedwith EMPTY/FULL boolean

repeat.with EMPTY do

produce (MESSAGE,B)EMPTY = falseFULL = true

.

.until false;


repeat.with EMPTY do

produce (MESSAGE,B)EMPTY = falseFULL = true

.

.until false;


repeat.with FULL do

consume (MESSAGE,B)EMPTY = trueFULL = false

.

.until false;


repeat.with FULL do

consume (MESSAGE,B)EMPTY = trueFULL = false

.

.until false;


Controlled shared variables

write v1,v2,v3,v4

Task S1 Task S1

wait v1<0 and v3<100

Task R1Task R1

wait (v2 + v3) > 0 or (v1 - v4) < 20

Task R2 Task R2

C.S.V.C.S.V.

v1

v2

v3

v4


HLM: Monitors

• definition– A monitor is a

concurrency construct that contains both the data and procedures needed to perform allocation of a particular serially reusable shared resource or group of serially reusable shared resources.

type monitor-name = monitorvariable declarations

procedure entry P1 (... ...);begin ....... .......end;

procedure entry P2 (... ...);begin ....... .......end;

procedure entry Pn (... ...);begin ....... .......end;

begininitialization code

end


Monitors 1

shared data

initialization code

. . . . . .

operators

entry queue


Monitors 2

shared data

initialization code

. . . . . .

operators

entry queue

x

ynext

var x,y: condition

x.wait

x.signal


Monitor example

• Simple resource allocation

monitor resource_allocator;var resource_in_use: boolean;

resource_is_free: condition;procedure get_resource;

beginif resource_in_use then

wait(resource_is_free);resource_in_use := true;

end;procedure return_resource;

beginresourc_in_use := false;signal(resource_is_free);

end;begin

resource_in_use := false;end;


HLM: Path expressions

• specify the order in which procedures are to be executed

path read end

path begin_reading, read, finish_reading end

path {read} end

path read|write end


HLM: Message Passing

• elements

• blocking send - non blocking send– synchronous - asynchronous

communication

• examples– mailboxes and ports– pipes– RPC

send (receiver_process, message);receive (sender_process, message);


Mailboxes - Queues: multiple senders & receivers

Task S3 Task S3

send Msg

Task S2 Task S2

send Msg

send Msg

Task S1 Task S1

rcv Msg

Task R1Task R1

rcv Msg

Task R2 Task R2

ExchangeExchange


Mailboxes - Queues: multiple senders one receiver

Task S3 Task S3

send Msg

Task S2 Task S2

send Msg

send Msg

Task S1 Task S1

rcv Msg

Task R1Task R1ExchangeExchange


Pipes

send

Task S1 Task S1

rcv

Task R1Task R1PipePipe


Remote Procedure Calls

• a process on one system can call a procedure in a process on another system

• calling process blocks pending the return from the called procedure

send (remote_process, input_parameters);

receive remote_process, output_parameters);


M3d: Deadlock & starvation


Deadlock & Starvation

• Deadlock– The process will never finish because

shared resource is locked

• Starvation– Process will never get high priority

enough to get to the resource


DL: Conditions• a P claims exclusive control of a resource• P holds allocated resource while waiting

for other resources (wait for condition)• Resources cannot be removed until used

to completion (no pre-emption condition)• There is a circular chain of processes in

which each process holds one or more resources that are requested by the next process in the chain (circular wait condition)


Deadlocks

P1

wait(S);wait(Q);.....signal(S);signal(Q);

P1

wait(S);wait(Q);.....signal(S);signal(Q);

P2

wait(Q);wait(S);.....signal(Q);signal(S);

P2

wait(Q);wait(S);.....signal(Q);signal(S);


D: example 1


D: example 2

Process BProcess A

Resource 1

Resource 2


D: example 2b

Process BProcess A

Resource 1

Resource 2


D: example 3

• Spooler– print files if file is closed and complete– what if not enough disk space for the

files?.....– ......deadlock


Starvation - Indefinite Postponement

P1

wait(S);......signal(S);.

P1


P6


P6


P5


P5


P4


P4


P3


P3


P2


P2



DL: Resource Concepts

• OS = resource manager• resource should be pre-emptible• non pre-emptible resources exists

– Tapes = dangerous to use in RT environment!!

• shared and non shared resources• Re-entrant code• serially reusable code


DL: Prevention 1• Definition:

– condition a system to remove any possibility for deadlock

• Havender’s strategies:– each process must request all its required

resources at once and cannot proceed until all have been granted

– if a process is denied further request, it should release all original resource and ask them back later

– impose linear ordering of resource types on all processes

• Price to pay: bad resource usage

RT-OK

RT-NOK


M3e: Good RTOS requirements


reduce application code length

A good RTOS needs to provide simple AND complex primitives. The complex primitives execute slower but may

reduce application code substantially.

A good RTOS needs to provide simple AND complex primitives. The complex primitives execute slower but may

reduce application code substantially.


Simple or complex objects??

• Simple: if I have one synchronisation primitive I may construct anything else BUT WHO is going to MAINTAIN the code????

• Complex objects– efficiently executed in OS– reduce maintenance– behaviour problem may be solved by

standardisation


Synchro in language or RTOS?

• Example: ADA• Ada includes synchronisation

primitives– Translated to supported runtime– In most cases runtime is not good

enough– Use of RTOS as runtime


Having as much synchronisation

primitives as possible.

A good RTOS needs as much synchronisationand communication primitives as possible.

This expresses the RTOS « richness ».It should also deal with priority inversion.

A good RTOS needs as much synchronisationand communication primitives as possible.

This expresses the RTOS « richness ».It should also deal with priority inversion.


RTOS richness - comparisonMechanism Richness

INTime1.20

RTX 4.1 Hyperkernel4.3

Task or thread management 78% 67% 50%

Clock 33% 33% 29%

Interval Timer 33% 67% 17%

Memory Partition 33% 17% 0%

Memory Heap 0% 43% 14%

Interrupt Handling 83% 50% 50%

Counting Semaphore 29% 14% 0%

Binary Semaphore 0% 0% 14%

Mutex 25% 25% 0%

Conditional Variable 0% 0% 0%

Event flags 0% 0% 0%

Signals 0% 0% 38%

Queue 0% 0% 0%

Mailbox 10% 0% 0%

AVERAGE PERCENTAGE: 23% 22% 15%


VxWorks 5.3.1 pSOSystem 2.2.6 QNX 4.25

Task management

94 % 75 % 50 %

Clock and timer 78 % 47 % 85 %

Memory management

77 % 73 % 27 %

Interrupt handling 38 % 25 % 75 %

Synchronization & exclusion objects

60 % 31 % 25 %

Communication & message passing objects

40 % 36 % 31 %

TOTAL PERCENTAGE

63 % 44 % 40 %


Object queue length independance

The behaviour of an RTOS should be independent of the numberof objects waiting in a queue.

The behaviour of an RTOS should be independent of the numberof objects waiting in a queue.


RTOS Queues

• Ready list• Waiting on synchronisation object• ..


Intime - RTX comparisonSemaphore Synchro

Task synchronisation

0

10000

20000

30000

40000

50000

60000

90000 100000 110000 120000 130000 140000 150000

absolute time (µs)

even

t d

ura

tio

n (

ns)

RTX INTime


Good RTOS – REQ:known memory footprint

The memory footprint should be knowfor different configurations.

The memory footprint should be knowfor different configurations.


CE Memory Footprint

• Minimum:– low end system

• kernel + communications + stacks - no display + application

– 500 KB ROM - 350 KB RAM

• Typical footprint– Handheld PC– 2 MB ROM - 512 KB RAM


allocate ALL system resources

BEFORE use

All system resources should be allocated beforethey are used the first time.

All system resources should be allocated beforethey are used the first time.


NT 4.0 acquire counting

semaphore

300

3870

7440

11010

14580

18150

21720

25290

28860

32430

36000

0 5000 10000 15000 20000

absolute time (µs)

even

t d

ura

tio

n (

ns)

1

1000

1000000

300 3870 7440 11010 14580 18150 21720 25290 28860 32430 36000

time (ns)

nb

r o

f ev

ents

Number of samples Minimum (ns) Maximum (ns) Average (ns)

8191 3150 33060 3161.1


M3f: Case study


• Behaviour problem


low-prioritythread

acquiremutex

launchmedium-priority

thread

busyloop

releasemutex

end

end

begin

medium-prioritythread

launchhigh-priority

thread

busyloop

end

end

begin

high-prioritythread

acquiremutex

busyloop

releasemutex

end

end

begin

Priority inversion testexpected behaviour


low-prioritythread

acquiremutex


thread

busyloop

releasemutex

end

end

begin


launchhigh-priority

thread

busyloop

end

end

begin

high-prioritythread

acquiremutex

busyloop

releasemutex

end

end

begin

Priority inversion testMLV behaviour - Hitachi


end

low-prioritythread

acquiremutex


thread

busyloop

releasemutex

end

end

begin


launchhigh-priority

thread

busyloop

end

end

begin

high-prioritythread

acquiremutex

busyloop

releasemutex

end

begin

priority inversion testobserved behaviour- x86


low-prioritythread

launchhigh-priority

thread

end

begin

high-prioritythread

acquiremutex

acquiremutex

busyloop

busyloop

releasemutex

releasemutex

end end

end

begin

busyloop

busyloop

Simpler test – expected behaviour

MVL_P_2.1: X86 - OK

Dedicated Systems Experts – 2005 – Martin TIMMERMAN p. 96end

low-prioritythread

launchhigh-priority

thread

begin

high-prioritythread

acquiremutex

acquiremutex

busyloop

busyloop

releasemutex

releasemutex

end end

end

begin

busyloop

busyloop

Simpler testMVL –Hitachi- behaviour


low-prioritythread

high-prioritythread

acquiremutex

acquiremutex

releasemutex

releasemutex

… …

Simplest test – expected behaviour

MVL_P_2.1: X86 - OK


low-prioritythread

high-prioritythread

acquiremutex

acquiremutex

releasemutex

releasemutex

… …

A

B

C

D

Simplest testMVL – Hitachi - behaviour


Path Minimum (µs) Maximum (µs) Average (µs)

A 83 84 137

B 82 87 83

C 332 397 376

D 19229 19477 19353

low-prioritythread

high-prioritythread

acquiremutex

acquiremutex

releasemutex

releasemutex

… …

A

B

C

D

NOT usable for RT

= fair scheduling


time

spurious thread activation – x86 & Hitachi

time

high

low

create cancelexpectedbehaviour(QNX like)

prioritylevel

high

low

create cancelAcceptedBehaviour(Unix like)


MontaVistadefault LSP

MontaVistawith

RT patches

high

low

create cancel

spurious thread activationhigh

low

create cancel

create thread cancel thread

create thread cancel thread


prioritylevel

time

high

low

create cancelexpectedbehavior

prioritylevel

time

high

low

create cancelMontaVistadefault LSP

prioritylevel

time

high

low

create cancelMontaVistawith RT patches

spurious thread activation – x86 & Hitachi

OK

OK

NOK

Topic under discussion with MV – to be followed!


prioritylevel

time

high

low

createN threads

expectedbehavior

prioritylevel

time

high

low

MontaVistawith RT patches

thread switch latency test - malfunctioning “yield” – Hitachi & x86

...

suspend

yield…yield…yield…between N threads

create1st thread

yield…yield…end

create2nd thread

yield…yield…end

prioritylevel

time

high

low


create1st

sleep

adapted test

create2nd

sleep...

createNth

sleep...

suspend

yield…yield…yield…between N threads

Yield = kill the thread


results of thread switch latency testfor 128 threads


adapted test

MontaVistadefault LSPadapted test

min 4.7smax 6911.9savg 7.8s

min 34.7smax 198.1savg 55.2s


X86 < - >Hitachi

• X86 behaves almost correctly• Hitachi does not behave correctly at

all

It IS important to validate an RTOS on different platforms!


M2g: Application design hints


Example 1screen memoryTask ATask A

Task BTask B

Task CTask C

solution 1: semaphoressolution 2: server task

solution 1: semaphoressolution 2: server task


Example 1: server task solutionscreen memoryTask ATask A

Task BTask B

Task CTask C

Server TaskServer Task


Example 2disk (data base)Task ATask A

Task BTask B

Task CTask C



Example 3

Task ATask A

Task BTask B

Task CTask C


Task ATask A

Task BTask B

Task CTask C


Comm line


Example 3

Task ATask A

Task BTask B

Task CTask C


Task ATask A

Task BTask B

Task CTask C

Server TaskServer TaskComm line 1

Comm line 2

easy to design,

implement,

test and maintain

easy to design,

implement,

test and maintain


Example 4: monitoringscreen memoryTask ATask A

Task BTask B

Task CTask C


Monitoring TaskMonitoring Task log report


M3h: Conclusions


CONCLUSIONS

• Synchronization and Communication is a complex issue

• A lot of flavours are possible in the primitives

• What about standardization?• The behaviour is the most important

issue!• Each OS has different behaviour –

portability issue.

dedicated systems experts 2005 - martin timmerman p. 1 rtos: the state of the art module 3...

Documents