Design of multitask software The entity-life modeling approach Dr. Bo Sandén Colorado Technical University Colorado Springs [email protected] 19 December

Design of multitask software

The entity-life modeling approach

Dr. Bo Sandén

Colorado Technical UniversityColorado Springs

[email protected]

19 December 2012

9/10/2012 Bo Sanden, CTU 2

Agenda

1. Introduction2. Tasks and protected objects3. State diagramming4. ELM concepts5. Design patterns based on event threads6. Event-thread patterns for resource sharing7. Simultaneous access to shared objects Conclusion

• Reference: • Bo I. Sanden, Design of multithreaded software: The entity-life modeling

approach, Wiley/IEEE Computer Society 2011• Errata: member.acm.org/~bsanden/Errata.pdf


1. Introduction

• Tasks are often seen as a pragmatic engineering devices– Especially when not part of the programming language

• Or, the architecture is centered on provable schedulability– Periodic tasks, hard deadlines and rate-monotonic scheduling

• Some problems aren’t really periodic, or • the deadlines are not really hard

• ELM makes tasks integral parts of the logical design– As independent as possible of practical concerns of the day

• Such as actual hardware, number of processors, etc.

• With multiple cores/processors,– proving schedulability is less urgent


Analogy with object-oriented modeling(4.2.1)

• OO programming languages provide classes and associations.– Classes capture certain aspects of the problem– We identify domain objects that map onto classes

• Ada also provides tasks.– Can they capture some aspect of the problem?– What in the domain maps to tasks?

• Tasking has primarily to do with time:– Each task goes on independently concurrently with others


Entity-life modeling (ELM)• Principle for designing task architectures• Each task is based on an event thread in the problem domain

– It processes a sequence of event occurrences that are separated in time

– An event is something that can happen• It can have any number of concrete occurrences

• The architecture is designed with a lighter touch – Than with common stepwise methods.

– ELM bases the task architecture directly on the problem

– It encourages trying out different architectures [Perry and Wolf 1992]• Designers often stick to a first solution


Task architecture

• Structure of tasks and protected objects– with a minimum of additional packaging

– A.k.a. the concurrency view of the architecture– Not: algorithms, data structures …

• A “concrete abstraction”– Allows concrete work at an abstract level– Exposes real problems that must be solved

• Describes a working machine, not a module structure

• Self-contained– Every instruction is executed by a task

• Except for event/interrupt handling

• More compact than the full architecture– Easier to reason about

ELM conceptsNot in book; similar to [Sandén]

Event-thread model

Event thread

Problem Software

1 0..1

1

1..*

1

Based onEntity

Task architecture

*

*

1

* Calls *

*

*

Based on

Protected object

Operations

*

Task

Priority

1 1

10/26/2012 7


Reactive software

• Some software systems exhibit– “a reactive behavior, whereby the system is not

adequately described by specifying the output that results from a set of inputs, but, rather, requires specifying the relationship of inputs and outputs over time”

David Harel

• Broader term than “real-time”– Includes many interactive systems

• Roman aqueduct bridge at Segovia, Spain (1st or 2nd century AD)

– With structural steel we could build it faster and more easily

– But new tools and materials also make much bolder structures possible

– So, too, with tasks


New tools and materials require new design techniques


2. Support for multitasking

• Tasks• Timing events (2.3.2.5)

• Protected objects– Controlling access to shared domain resources

(2.3.2.6)

• Semaphore solution• Monitor solution

– Other protected objects

• Asynchronous transfer of control (ATC)

10/27/2012 Bo Sanden, CTU 11

Tasks and task types

• Tasks proceed concurrently– Often, each on its own processor/core

• Interact via protected objects• Can control their timing by means of the

statements delay delay until

– Tasks can be periodic:• Samplers, regulators, output generators


Timing events

• In Ada 2005, periodic actions need no tasks– Operations (on protected objects) can be invoked by instances of type

Timing_Event

• A variable, say Auto_Time : Timing_Event creates an event thread:– A sequence of event occurrences set apart by some minimum time

• A time span and a handler (Time_Out) are tied to Auto_Time: Set_Handler (Auto_Time, Time_Amount, Time_Out’Access)– Time_Out is a protected procedure

• Another Set_Handler call cancels this and can change the time span and/or the handler


Protected objects (POs)• Handle synchronization and communication of tasks

• Protected procedures:– Exclusion synchronization (write lock)– Only one task at a time gets to update the object

• Protected functions:– Read lock: Many callers only retrieving data can share the lock

• Protected entries:– Condition synchronization: Tasks wait on a condition for access– Then execute the entry under write lock

• All protected operations should be short– “Nearly instantaneous” execution– If they cannot be short, the waits must be shown in the state model

• Note: Called “safe” on some slides; a language-neutral, ELM term


Interrupt and timing-event handling

• Protected procedures can be – interrupt handlers– event handlers called by timing events:

protected body Window_Control is … procedure Time_Out (Event : in out Timing_Event) is

begin …. Set_Handler (Auto_Time, Time_Amount, Time_Out’Access); end Time_Out; …

end Window_Control;


Special-purpose protected objects

• Tasks can be surrogates for resources users in the domain

• Control of access to shared domain resources:– Semaphore protected object

• Guards a domain resource• Basic operations:

– Acquire– Release

– Monitor package• Represents a domain resource• Operations on the shared resource encapsulated together

with a semaphore• Cannot be a PO


Semaphore protected objectfor a forklift in a flexible manufacturing system (FMS)

protected Forklift_Semaphore isentry Acquire;procedure Release;

private Busy : Boolean := False;

end Forklift_Semaphore;

protected body Forklift_Semaphore isentry Acquire when not Busy isbegin

Busy := True;end Acquire;

procedure Release isbegin

Busy := False;end Release;

end Forklift_Semaphore;


Monitor packagepackage Forklift_Monitor is

procedure Use_Forklift ( … );

end Forklift_Monitor;

package body Forklift_Monitor is

protected Forklift_Semaphore is …

protected body Forklift_Semaphore is …

procedure Use_Forklift ( … ) is

begin

Forklift_Semaphore.Acquire;

… -- Critical section: Operate the forklift

Forklift_Semaphore.Release;

end Use_Forklift;

end Forklift_Monitor;

More advanced: Distributed semaphore

• Nodes in a distributed system use a common semaphore for mutual exclusion:– Acquire sends messages to K nodes

– Maekawa’s algorithm [Coulouris et al 2012]

– The node task requeues on Replies_Collected until all replies are in

– Another task receives replies • calls Reply_Received for each one

– Release sends messages to K nodes– The PO on the next slide is a semaphore PO

• especially if the interface could be hidden except for Acquire and Release


protected body Maekawa_Semaphore is

entry Acquire when Released is -- Attempt to gain exclusive access

begin

state := Wanted

- - Multicast request to all processes (including self)

requeue Replies_Collected;

end;

entry Replies_Collected when (Replies = K) is

begin

state := Held; -- This node now has exclusive access

Replies := 0; -- Initial value is also 0

end;

procedure Reply_Received is

begin

Replies := Replies + 1:

end;

procedure Release is …. -- Release exclusive access

procedure Request_Received is ….

procedure Release_Received is ….

end Maekawa_Semaphore;



State-machine protected object

• Represents a state machine– Maekawa Semaphore is an example

• Operations:– Event handlers change the state and/or take actions

• There is typically one per event • By definition, events and actions are (nearly) instantaneous• Ex.: Release, Reply_received in Maekawa_Semaphore

– State-wait entries lets a task wait until a certain state is entered

• Ex.: Acquire in Maekawa_Semaphore

– etc., Chapter 5


Other protected objects Ex.: Leader/followers pattern


Task set in leader/followers pattern protected Task_Set is entry Join_Set; procedure Promote_New_Leader; private Leader_Exists : Boolean := False; end;

protected body Task_Set is entry Join_Set when not Leader_Exists is begin Leader_Exists := True; end; procedure Promote_New_Leader is begin Leader_Exists := False; end; end;

Pseudo-Ada for C_Serve tasks

beginloop

Task_Set.Join_Set;--This task is now the leaderpend on event on Handle setdemultiplexTask_Set.Promote_New_Leader;process message

end loop;end;

12/7/12 23


Queue protected object

• Holds requests for access to a shared resource (Ch. 6)

– Must guard against overflow• The queue size must be bounded• Many special solutions possible:

– The queue can be represented by 2 numbers:» As in a queuing system for a bank office.

– It can be a circular buffer with older items overwritten» As in a Remote Temperature Sensor

10/15/2012 Bo Sanden, CTU 25

2.3.3 Asynchronous transfer of control (ATC)

• A computation in a task can abort when an entry call is accepted • Ch. 7

• The Ada syntax is quite elegant• Compared with Real-time Java

• This variant times out a computation in a task:

select delay until Next_Reading;then abort

<some computation>end select;

• <some computation> starts. – If not done by Next_Reading, it is aborted.

General ATCselect trigger

[optional sequence of statements]then abort

<abortable sequence of statements>end select;

• The trigger is either a delay statement or an entry call.

– If it is an entry call or a delay that has not expired:• the <abortable sequence of statements> begins.

– If the triggering event completes before the abortable sequence ends:• the abortable sequence is aborted, • the <optional sequence of statements> executes.

– If the <abortable sequence of statements> completes first:• the trigger is cancelled • the next statement after the select statement executes.

11/5/2012 26


3. State modeling

• An domain entity can exist in different states:– A garage door can be Closing, Closed, Opening,

Opened, etc.

• An event can change the state:– click takes it to Opening or Closing– top takes it from Opening to Open, etc.

• An event occurs at a specific, unique time – Similar to the letter ‘c’ and its multiple occurrences on this slide


Garage door[Sandén 2012]

Example from [Bass et al. 2003]

Closed

Closing Opening

Stopped-closing

Stopped-opening

Opened

click/start up

click/stopclick

[clear]/ start down

click [clear]/ start down

click/ stop

click/start up

break/start up

bottom/stop

top/stop

do/check optical sensor

Sensing S sec/start up


• States: Closed, Open, etc.– Closed is marked as the initial state

– Superstate: Sensing

• Events: click, top, bottom, break, etc.– Time event: S sec. (or S seconds)

– Other kinds: Allocation events

• Actions (on the door motor): start up, stop, break– (Nearly) instantaneous

• Activity: check optical sensor (throughout Sensing)– Not (nearly) instantaneous; takes time

– Can be implemented with task or timing events (if it is periodic)

– Note: Another design of the garage door system could eliminate the superstate Sensing and make check optical sensor local to state Closing.

State-diagramming conventions

S

Tentry/a3exit/a4do/c1

e1 / a1 U

entry/a7

We5

e3 [cond] /a5

entry / a6do / c2

v

e4

• Keywords entry and exit designate actions taken upon transition to and from a (super)state

• An arrow from a superstate border applies to all substates



Kinds of activities

• Nominal activities: – Example: Apply heat (as in a toaster)

• Reduces to 2 actions: heat_on and heat_off

• Software activities:– Computation– Waiting for access to resource– Waiting for blocking operations

• Periodic activities can be nominal if using timing events– Sampling (such as check optical sensor)– Regulation (feedback loop)

Window elevator for a car(referenced later)

5/7/2012 32

• In a particular car model, the driver side window is operated by a lever

• Events: top, bottom– up: Window moves up– release: Window stops– down: Window moves down

• If lever held for S seconds, the window opens automatically

• up: Window stops

• States: – Still, Moving up, Prel down, Auto down

Car window elevator

Stillentry/stop

Prel. downentry/start down

Moving upentry/start up

Auto down

down [not fully open]

bottom

S seconds

up

release

bottom

releasetop up [not fully closed]

5/7/2012 33

4. ELM Concepts

Event-thread model

Event thread

Problem Software

1 0..1

1

1..*

1

Based on

Resource-user thread

Resource-guard thread

Entity

Task architecture

*

*

1

Calls

*

*

Based on

State-machine protected

object

Sequential-activities

task

Activity task

Protected object

Operations

*

Task

Priority

MonitorSemaphore

Acquire Release

(Not in book)

11/3/2012 34


Event threads• The events of interest in ELM are:

– those that the software being architected must react to and handle.

• Each event thread is a sequence of occurrences of essential events– The occurrences in each thread are separated in

time– Each event occurrence is part of exactly one

event thread

11/14/12 36

Event-thread examples• In the garage-door system:

– Door-operation: • top, bottom, S sec, click

– Sensor-checking• Sequence of time-event occurrences

• In the window elevator:– A single thread of inputs: up, down, release, bottom …

• In an elevator bank:– The events in the life of each elevator cabin form a thread

• arrived, doors opened, doors closed

• In a router: – The incoming messages on each communication line

• Any subset of the messages

• In an ATM:– The inputs by successive customers: login, password,


Essential events• The events in an event thread must be essential to the

problem.– Independent of a particular software design.

• Most are shared by the software and the domain– click, break, top, and bottom

• Time events– If significant in the problem domain

• Some essential events are not shared– The occur inside the software:

• Allocation event: a domain entity acquires a resource.• The completion of a computation

– If the computation is necessary no matter the software design– It should be a significant completion, not just a small step


Event-thread models

• Together, the event threads form an event-thread model of the problem– The event threads partition the set of essential-event

occurrences• We can base a task on each event thread

– It handles each event occurrence• Or we can use timing-event/interrupt handlers• A single event thread may give rise to tasks in multiple computers

– Multi-tier transaction systems, for example

• It’s a good idea to consider and compare different event-thread models of a given problem– Can lead to thread architectures with significantly different properties


Event-thread model examples

• Garage door problem: – Sensor-checking and Door-operation

• Implemented with interrupt/timing-event handlers

• The car window: A single event thread• The elevator bank:

– All the elevator threads– Threads of requests for service

• The router – Maybe one thread per line

• The ATM system– An event threads for each individual ATM


Finding event-thread models Example: Simple elevator-bank

• A bank of elevators E1, E2, … serve all the floors F1, F2, … of a hotel or office building

• We are interested in events that the software must react to– Specifically (in this simple example):

• An elevator arrives at a floor

• The doors, Dn, of elevator En open

• The doors close

• The elevator leaves a floor

• We partition the event occurrences in different ways to find thread models.


Event trace in the elevator-bank Ei: Elevator i; Di: Door of elevator i; Fj: Floor j

• E2 arrives F2• D2 opens F2• E3 leaves F1• D2 closes F2• E1 arrives F1• E2 leaves F2• E3 arrives F2• D1 opens F1• D3 opens F2• D1 closes F1• D3 closes F2• E1 leaves F1• E2 arrives F3• E3 leaves F2• E1 arrives F2• D2 opens F3• D1 opens F2• D1 closes F2• E3 arrives F3• D2 closes F3• E1 leaves F2• E2 leaves F3• E1 arrives F3


1. Partitioning the events per floorE2 arrives F2

D2 opens F2

E3 leaves F1

D2 closes F2

E1 arrives F1

E2 leaves F2

E3 arrives F2

D1 opens F1

D3 opens F2

D1 closes F1

D3 closes F2

E1 leaves F1

E2 arrives F3

E3 leaves F2

E1 arrives F2

D2 opens F3

D1 opens F2

D1 closes F2

E3 arrives F3

D2 closes F3

E1 leaves F2

E2 leaves F3

E1 arrives F3

• The event occurrences are partitioned per floor

• But the occurrences in each set are not always separated in time– E2 leaves F2 and E3 arrives F2

can be at the same time

• So, the event occurrences for a floor do not form an event thread– This is not a legitimate event-

thread model


2. One event thread per elevator and one per door E2 arrives F2

D2 opens F2

E3 leaves F1

D2 closes F2

E1 arrives F1

E2 leaves F2

E3 arrives F2

D1 opens F1

D3 opens F2

D1 closes F1

D3 closes F2

E1 leaves F1

E2 arrives F3

E3 leaves F2

E1 arrives F2

• The occurrences in each thread are now separated • New concern: Too much concurrency

– An elevator’s doors open only when it’s stopped at the floor– A legitimate thread model, but not optimal


3. Combine elevator events and door events

E2 arrives F2

D2 opens F2

E3 leaves F1

D2 closes F2

E1 arrives F1

E2 leaves F2

E3 arrives F2

D1 opens F1

D3 opens F2

D1 closes F1

D3 closes F2

E1 leaves F1

E2 arrives F3

• This is an optimal thread model– It’s as concurrent as the problem itself

• Intuitively, elevator and door events are part of the same thread• In an implementation:

– We can give each elevator a task, or– Let interrupt handlers deal with the event occurrences

12/19/2012 45

Co-occurrence

• Some threads in Model 2 are synchronized– The elevator thread and its door thread don’t make progress

concurrently/independently

• If they did, they would − once in a while − have events occurring at the same time by coincidence– This is the case for the 3 elevator threads

– It is not the case for an elevator and its door

• Intuitively, think of a snapshot of events occurring at once:– Picture all elevators arriving at (different) floors at one time, for example

• More strictly, two threads are said to co-occur if:– You can construct an arbitrarily short time interval where each may have a

different event occurrence

12/19/12 46

Optimal thread models. Concurrency levels

• A thread model is optimal if all its threads co-occur: – There can be a time when each thread has an event occurring.

• All optimal thread models of a given problem have the same number of threads– This number is the concurrency level of the problem.

– Equals max number of simultaneous occurrences in the problem

• Ex.: There can be at most one occurrence for each elevator at a given time.

– The concurrency level = the number of elevators• (We are ignoring button events for now)

• Note: ELM does not require that all thread models be optimal


Threads and entities• Often we can associate an event thread with an entity in the problem

– An entity is something whose life history is an event thread

– In the elevator bank, each cabin has a thread of events happening to it: • arrived, doors opened, doors closed, etc.

– Hence the name “entity-life modeling”

• Alternative entities in the elevator problem:– A door entity is OK but unnecessary.

• It can be incorporated into elevator

– There is no legitimate floor entity. • Events can occur simultaneously at any floor

– What about elevator-floor entities?• They can easily be combined into fewer entities/event threads

• Note: If the entity is a person, software usually deals with events that the entity produces


Long-lived threads

• A long-lived thread stays in the problem a long time.– An operator thread– An elevator thread

– This is generally desirable• Reduces overhead for task creation, etc.

– Maybe also safer/more secure» Less dynamic allocation

• Short-lived threads come and go– A single transaction as from an ATM– Short-lived threads can often be combined:

• A sequence of transactions from the same ATM

Chapter 4 Conclusion

• Based on the foundations of ELM, we shall now look more in depth at:– Basing multitask software on one (or more) state

machines• Chapter 5

– Dealing with resource sharing in the problem• Chapter 6

– Dealing with simultaneous exclusive access to multiple resources

• Chapter 7


12/19/2012 Bo Sanden, CTU 50

5. Design patterns based on state machines

• Some (simple) problems center on a single state machine– Car window, classic cruise controller

• In more complex problems:– Individual event threads captured as state machines

• This covers all discrete-event driven systems

• The software activities need tasks• Noted in Chapter 3

• The state machine itself is a passive object

Design patterns

• Concurrent-activities pattern– Participants:

• A state-machine protected object• Activity tasks (for any software activities; possibly none)

• Sequential-activities pattern– Participant:

• One sequential-activities task– Handles one software activity at a time

» The activities don’t co-occur– The task also keeps track of the state

12/19/2012 51


5.2 State machines without software activities

• No tasks

• State-machine protected object:– State variable– Other, related variables

– Operation types• Event handlers (interrupts and time events)• State queries• Parameter queries


Window elevator(fragment of a state diagram in Ch. 3)

• Events (and event handlers):– The driver depresses the lever

• The window starts moving down– Lever released

• Window stops– Auto_Time seconds:

• The window continues down on its own

Still Prel_Down Auto_Down

Lever_Down

ReleaseAuto_Time


protected body Window_Control is procedure Lever_Down isbegin if Wstate = Still then

Wstate := Prel_Down; Set_Handler (Auto_Time, Time_Amt, Time_Out ‘Access); end if;end Lever_Down;

procedure Release is Cancelled : Boolean;begin

if Wstate = Prel_Down thenWstate := Still; Cancel_Handler (Auto_Time, Cancelled); -- Stop window

motor else … -- other states

end if;end Release;

procedure Time_Out (Event : in out Timing_Event) isbegin if Wstate = Prel_Down then Wstate := Auto_Down; end if; -- Time_Out is ignored in other statesend Time_Out;

end Window_Control;


Bike odometer

A

A

A

A

Distance

B / dist:=0/display distdo / display dist every

200 ms

Speed

do / display speed every 100 ms

Mileage

do / display mileage every 500 ms

Time

B/time:=0/display timedo / display time

every second


protected body Odometer isfunction Rel_Dist return Display_Type is begin return Display_Type (Wheel.Dist - Ref_Dist); end;function Rel_Time return Display_Type is

begin return Display_Type (Calendar. "-" (Calendar.Clock, Ref_Time)); end;

procedure A_Pressed isbegin

if State = Tyme then State := Distance;else State := State_Type'Succ (State); end if;Set_Handler (Refresh, Time_Span'(Seconds (0)), Handler_Array (State));

end;

procedure B_Pressed isbegin

if State = Distance then Ref_Dist := Wheel.Dist;elsif State = Tyme then Ref_Time := Calendar.Clock; end if;

end;

procedure Distance_Handler (Event : in out Timing_Event) isbegin

Display (Rel_Dist); Set_Handler (Refresh, Delay_Array (Distance), Distance_Handler'access); end;

procedure Speed_Handler (Event : in out Timing_Event) isbegin

Display (Wheel.Speed); Set_Handler (Refresh, Delay_Array (Speed), Speed_Handler'access);end;

procedure Mileage_Handler …..procedure Time_Handler ....

end Odometer;


State machines with software activities

• Two design patterns:– Sequential-activities pattern (5.3)

• All activities in one task– It also keeps track of the state

– Concurrent-activities pattern (5.4)• A state machine object (as before)• Software activities are tasks

– State machine without software activities is a degenerate case


5.3 Sequential-activities pattern

• Works if there are only non-co-occurring software activities– The state model represents a single entity type

• Usually with multiple entity instances

• One sequential-activities task:– Performs software activities one after the other– Keeps track of the current state

• Explicit state representation– There is a state variable

• Implicit state representation– Different parts of the task logic represent the different states

» No state variable needed– The task logic reads from top to bottom– Like a sequential program

11/12/2012 Bo Sanden, CTU 59

Example: Home heating

• A single task represents a heater in one home – Takes it through its start-up motions– Maintains heating while necessary– Takes the heater through its shut-down

procedure

– The task text matches the following pseudocode line by line


Home heatingWait for master switch to be OnWhile system is on:

While room needs no heating:Turn off system when master switch is turned Off

Start-up procedure:Start motor; wait 7 secondsIgnition onOpen fuel valve; wait 3 seconds

While room needs heating:Initiate turn-off within 5 seconds of either:

1. Master switch turned Off2. Motor status changes to Off3. Fuel flow status changes to Off4. Combustion status changes to Off

Indicate abnormal status for 2 – 4: Furnace restarted only by master switch.Shut-down procedure:

Close fuel valve; wait 5 secondsDeactivate motor and ignition; wait 3 seconds

Allow for cool-down.

Sequential-activities task: Odometer begin

loop

-- Distance state

Next := Clock + Dist_Delay;

D: loop

select Buttons.Pressed (Button);

case Button is

when A => exit;

when B => Ref_Dist := Wheel.Dist;

end case;

or delay until Next; Display (Wheel.Dist - Ref_Dist); Next := Next + Dist_Delay;

end select;

end loop D;

-- Speed state

Next := Clock + Speed_Delay;

S: loop

select Buttons.Pressed (Button);

case Button is

when A => exit;

when B => null;

end case;

or delay until Next; Display (Wheel.Speed); Next := Next + Speed_Delay;

end select;

end loop S;

-- etc., for the Mileage and Time states

end loop;

end Odometer;



5.4 Concurrent-activities pattern

• State-machine protected object – State variable

– Operation types:• Event handlers (interrupts and time events)• State queries• Parameter queries• State-wait entries (called by activity tasks)• State-dependent operations

• Activity tasks

• Note again that a state-machine with no software activities (5.2) is a degenerate case without tasks

– No state-wait entries– No state-dependent operations

Activity task

• Associated with a (super)state– Could be a sampler or a regulator task, for example

• Calls operations on the state-machine protected object– May block on state-wait entries

• Usually to wait for a certain (super)state to be entered

– May query a parameter to determine further processing– May call state-dependent operations

• Certain activities may take effect in certain substates only

• In rare cases, communication is initiated from the state-machine protected object (5.4.2.2.1)– For this, the task uses an asynchronous select statement (2.3.3)


Examples

• Problems with a single, main state machine and multiple, co-occurring activities– Classic cruise control– Weather buoy

12/10/2012 Bo Sanden, CTU 64

Classic cruise control5.4.3.1

• The cruise controller for a car is a popular example of embedded software design

• The following state diagram is simplified from [Gomaa 2000]– (The ELM solution is compared with Gomaa’s approach in

Chapter 8)

• The tasks can be identified in the state diagram

• Note: This is really “your grandfather’s cruise control.”– There are interesting extensions:

• Automatic collision control may override the speed control

12/10/2012 Bo Sanden, CTU 65

Classic cruise control: State model5.4.3.1

Initial

entry/clear desired speed Cruising suspended

Accelerating

do/increase speed

Cruising

do/maintain speed

Engine running

Automated control

accel [brake off]

cruise/set desired speed

accel

offbrake

pressedresume

[brake off]

accel [brake off]

(do/sample driver controls)

off

do/control speed

12/10/2012 Bo Sanden, CTU 66

Cruise control: Software activities

• Increase speed and maintain speed are software activities:– By definition they do not co-occur

• They belong to distinct states

• Speed_Control is an activity task in superstate Automated Control

– It maintains constant speed in Cruising

– It maintains constant acc. in Accelerating

– This simplifies state transitions• It calls periodically the state-machine protected object Cruise_Control to

query the current state

• The activity sample driver controls (if necessary) belongs to superstate Engine Running– Separate activity task


Classic cruise control: communication diagram

cruise-control:Cruise-control

speed-control:Speed-control

get-crusing-state get-desired-speed

Brake:Brake

brake-pressed brake

interrupts

button interrupts

Speed:Speed

get-speed get-speed

speed input

brake-off?

12/10/2012 Bo Sanden, CTU 68

Weather buoy[Booch 1986]; 5.4.3.2

• Buoys at sea collect navigation and weather data in a repository (6.7)

• Regular transmissions of current data to ships occur every 60 sec

• Upon request, a history transmission of data collected over 24 hours are made – This preempts the regular transmissions

• A sailor in distress may engage an emergency switch and initiate an emergency transmission (SOS)– This preempts regular and history transmissions


Reporting state machine

Regular

Emergency

HistoryEnd of history

Reset

History request

Switch flipped

Normal


• One solution has an activity task for each kind of output• Suggested by Alan Brown, George Mason University

• A state-machine protected object is like a filter that lets messages through only in the right state

• This solution has more tasks than the concurrency level• Note that the extra task must be kept in check

• A sequential-activities task is also possible [Sandén 1994]

Weather buoy activity tasks

• Regular– Prepares transmission every 60 sec and calls Reporter.Regular_Msg

• History– Blocks on Reporter.Hold_History– When in state History, repeatedly calls Reporter_History_Msg

• SOS– Repeatedly calls Reporter.SOS_Msg and blocks until state is

Emergency

– Then sends SOS continuously

• State-dependent operations to manage the redundant tasks:– Reporter.Regular_Msg transmits a message only in state Regular

– Etc.

12/19/2012 Bo Sanden, CTU 71

State-machine protected objectprotected Reporter is

procedure Regular_Msg (....); -- Regular, periodic msg

-- (state-dependent op.)

procedure History_Request; -- Request for history data

entry History_Msg (....); -- Send history message

-- (requeues on Hold_History)

entry Hold_History; -- State-wait for History_Task

entry SOS_Msg (....); -- Send SOS if needed

procedure Reset; -- Emergency reset

private

procedure Switch; -- Emergency switch flipped

pragma Attach_Handler (Switch, ...);

State : State_Type := Regular;

end Reporter;


Sequential-activities solution in Ada 83 [Sandén 1994]loop begin -- Regular transmission Next:=Clock; Regular: loop Next:=Next+R_period; for E in Real_elt loop Send(Get_current(E)); end loop; select accept Emergency; raise SOS; or accept History; exit; or delay until Next; end select; end loop Regular; Iter24(Iter); Get_Next(Iter, It); -- History while It.Elem /= None loop Send(It); Get_Next(Iter, It); select accept Emergency; raise SOS; else null; end select; end loop; exception -- Emergency. May be rare enough to justify exception handling when SOS => Emergency: loop select accept Reset; exit; else Send_SOS; end select; end loop Emergency; end; end loop;


11/5 /2012 Bo Sanden, CTU 74

5.5 Communicating state machines

• Some systems can be modeled as networks of state machines– Often chains of state machines

• The state machines can be viewed as separate objects– Calling each other’s operations

• Small example:– The objects cruise-control and brake


5.5.1 Communicating state machines without software activities

Toy-car factory Dept. of Automatic Control, Linköping University, Sweden

Actual setup at Lund Institute of Technology, Sweden



Toy-car factory perspective

legoperspective.JPG


Toy-car factory layoutDept. of Automatic Control, Linköping University, Sweden

Fig 5-7.JPG

Chassis station

Strömberg, 1991. Used with permission.

Solution with protected objects(not included in book)

• Each station along the assembly line can be modeled as a state machine– Next slide: Chassis-station state diagram

• There are no software activities

• Each state machine becomes a protected object– Communicates with its neighbors via calls– The Chassis station includes a time event

10/27/2012 Bo Sanden, CTU 79

Waiting for bottom to arrive

Waiting for chassis store to be refilled

Waiting for pusher moving forward

Waiting for pusher moving back

Waiting for Press station

chassis store refilled / AE3F

F3 [chassis store not empty] / AE3F

Chassis Station 2012-11-02

AE3F: chassis pusher forward AE3B: chassis pusher back AE3S: chassis pusher stopAE2B: stopper back AE2F: stopper forward AE2S: stopper stop

G6: pusher in forward positionG5: pusher in back positionG3: stopper in back positionG4: stopper in forward position

/ ready to bottoms station

F3 [chassis store empty]

G6 / AE3BG5 [press station not

ready] / AE3S

Wait for stopper moving back

ready signal from press / AE2B

G5 [press station ready] / AE3S; AE2B

delay

G3Wait for stopper moving forward

Car_pass seconds / AE2FG4 / AE2S; ready signal to bottom

station

G3

Chassis station

11/2/2012 80

Protected object protected Chassis_Station is function Ready return Boolean; procedure Chassis_Store_Refilled; procedure Ready_From_Press;private procedure F3; procedure G6; procedure G5; procedure G3; procedure G4; State: State_Type := W_Bottom; Car_Pass: Timing_Event; Pass_Time : Ada.Real_Time.Time_Span; procedure Car_Pass_Handler (TE : in out Timing_event); pragma Attach_Handler (F3, ...); -- et cetera end Chassis_Station;


protected body Chassis_Station is function Ready return Boolean is begin …. end;

procedure F3 is begin if not Chassis_Store.Empty then Ae3f; State := W_Forward; else State := W_Refilled; end if; end;

procedure Chassis_Store_Refilled is begin if State = W_Refilled then Ae3f; else State := W_Forward; end if; end;

procedure G6 is begin Ae3b; State:=W_Back; end;


procedure G5 is begin Ae3s; if not Press_Station.Ready then State := W_Press; else Ae2b; State := W_Stopper_Back; end if; end;

procedure Ready_From_Press is begin Ae2b; State := W_Stopper_Back; end;

procedure G3 is begin Set_Handler (Car_Pass, Pass_Time, Car_Pass_Handler'access); end;

procedure Car_Pass_Handler is begin Ae2f; State := W_Stopper_Forward; end;

procedure G4 is begin Ae2s; Bottoms_Station.Ready_From_Chassis_Station; end;

end Chassis_Station;

Task solution for Chassis station

• Before there were timing events, a task was necessary– The states are implicit– Easier to understand than the protected object

• Because the state diagram is straightforward and “linear”

• Note: This solution uses task entries.


Chassis-station task (Ada 83 style)task body Chassis_Station isbegin

loopaccept Ready; -- Let Bottom station task proceedaccept F3; -- Wait for bottom to arrive Chassis_Store.Full; -- If store empty, wait until refilledAE3F; -- Pusher: forward.accept G6; -- Wait for pusher to reach pos.AE3B; -- Pusher: backaccept G5; -- Wait for pusherAE3S; -- Pusher: stopPress.Ready; -- Wait for Press taskAE2B; -- Stopper: backaccept G3; -- Wait for stopper to reach pos.delay Car_Pass; -- Allow car to proceedAE2F; -- Stopper: forwardaccept G4; -- Wait for stopper to reach pos.AE2S; -- Stopper: stop

end loop;end Chassis_Station;

12/19/2012 Bo Sanden, CTU 84


5.5.2 Communicating state machines with software activities

• Maekawa semaphore– Nodes must communicate to synchronize a single

critical section– Each needs communication activities

• Assembly-line workstations– Communicate to control exchange of parts– Could be extended to where each workstation needs

to communicate with multiple others

Logic in each assembly-line workstation

• When W1 is ready for a new part, it sends a request to W0 and waits for:– Info from W0, and

– The part to arrive on the conveyor and then to be picked

• It then waits for:– The assembly to finish, and

– Request from W2

• It then waits until the part is placed on the conveyor• Note: The state diagram has two orthogonal regions


W0 W1 W2

Conveyor

request

info

request

info

Waiting for arrived or

info

Waiting for arrived

Waiting for picked or info

Waiting for picked

Waiting for info Waiting for

assembled

Waiting for request

Waiting for placed

info

arrived/pick

info

picked picked/assemble info/

assemble

assembled [No request] assembled

[Request pending] /send-info/place

request/ send-info/

place

placed/reset

arrived/ pick

entry/send-requestdo/receive-info

WinfoWS

Req

No requestdo/receive-

request

Request pending

request

reset

5/19/2012 87

Communication

• When W1 wants an item, it sends a request to W0• It then receives an info message

– Request is sent upon entry to state Winfo– Receive info is a software activity in state Winfo

• Activity task: receive_info

• W1 can expect a request from W2 at any time– Receive request is a software activity in state No request

• Activity task: receive_request

• All other events are interrupts


State-machine protected object• Event handlers:

– arrived– picked– placed– assembled– info

• called by Receive_info when info message received

– request• called by Receive_request when request received

• State-wait operation– wait_for_Winfo

• Receive_info task waits until Winfo is entered

• Note: The orthogonal region Req has its own state variable


Summary of Chapter 5

• Decision table for implementing a state machine:– Are there software activities and they do not co-occur?

• Use a sequential-activities task– Consider implicit state representation

– Otherwise (co-occurring software activities or none at all): • Use a state-machine safe object

• Are there software activities?– Include activity tasks

• Chapters 6 and 7 center on resources and their users

11/19/2012 Bo Sanden, CTU 90


6. Event-thread patterns for resource sharing

• Tasks capture resource contention in the problem domain well– Access to domain resources can be aligned with access to internal

resources in sequential task logic

• In this chapter, each resource user needs exclusive access to only one resource at a time

• With exclusive access to two or more resources at once, the architecture must be designed to prevent deadlock – Chapter 7

• Note: The event threads in these chapters map onto tasks– The distinction between threads and tasks becomes irrelevant here


Dual solutions for resource sharing

• Usually two solutions are possible:– Resource-user threads

• Resource-user entities are often prominent in the problem– Often many instances of a single entity type

• Each resource user usually gets a sequential-activities task with implicit state

– Waiting for a shared resource is a software activity

– Resource-guard threads• Each such thread “owns” a resource and serves queued

requests from resource users• Resource-guard threads often form an assembly line

• The dual can offer a fresh look at the problem


Example (4.4.3) Bank-office queuing system

• Customers stand in a single (virtual) line– rather than one (physical) line per teller

position

• A machine issues a numbered ticket to each customer.

• The number currently served is displayed over head – together with a teller position number


Event trace in the bank officeCust. 1 arrivesTeller 1 gets Cust. 1Cust. 2 arrivesTeller 2 gets Cust. 2Cust. 3 arrivesCust. 4 arrivesTeller 3 gets Cust. 3Cust. 5 arrivesCust. 6 arrivesTeller 1 done with Cust. 1Teller 1 gets Cust. 4Teller 2 done with Cust. 2Cust. 7 arrivesTeller 3 done with Cust. 3Teller 3 gets Cust. 5Teller 2 gets Cust. 6Cust. 8 arrivesTeller 3 done with Cust. 5Teller 3 gets Cust. 7Teller 1 done with Cust. 4Cust. 9 arrivesCust. 10 arrivesTeller 1 gets Cust. 8


Trace partitioned per customer

Cust. 1 arrivesT1 gets Cust. 1

Cust. 2 arrivesT2 gets Cust. 2

Cust. 3 arrivesCust. 4 arrives

T3 gets Cust. 3Cust. 5 arrives

Cust. 6 arrivesT1 done with Cust. 1

T1 gets Cust. 4T2 done with Cust. 2

Cust. 7 arrivesT3 done with Cust. 3

T3 gets Cust. 5T2 gets Cust. 6

Cust. 8 arrives

T3 done with Cust. 5T3 gets Cust. 7

T1 done with Cust. 4T1 gets Cust.

8


Customer-task solution(Resource-user tasks)

• Solution with resource-user tasks– Each Customer task calls Teller-control to acquire and release a teller

• An unbounded number of short-lived tasks are created– The concurrency level is min (#customers, #tellers)

• On the other hand, individual customer behaviors can be modeled – This may be useful in a simulation of the bank office

<< shared>>tc: Teller-control

acquire

release

cn: Customer


Trace partitioned per teller plus a Customers event thread

Cust. 1 arrivesTeller 1 gets Cust. 1

Cust. 2 arrivesTeller 2 gets Cust. 2

Cust. 3 arrivesCust. 4 arrives

Teller 3 gets Cust. 3Cust. 5 arrivesCust. 6 arrives

Teller 1 done with Cust. 1Teller 1 gets Cust. 4

Teller 2 done with Cust. 2Cust. 7 arrives


Teller 2 gets Cust. 6Cust. 8 arrives


Teller 1 done with Cust. 4Cust. 9 arrivesCust. 10 arrives

Teller 1 gets Cust. 8


Teller-thread solution (resource-guard tasks)

Get_ticket

w: Wait_Line

Get_customer

cs: Customers

tn: Teller

• Each teller has an instance of a resource-guard task

• A single Customers task represents the arrival events– Could be done with event handling and no task

• All tasks are long lived

• The solution is usually optimal

• The queue of waiting customers cannot overflow:– It is represented by two numbers

6.5.1 Remote temperature sensor

• Monitors the temps. of a set of furnaces– A thermocouple connected to each furnace– Multiplexed A/D converter

• Located near the group of furnaces• Sends each temp. reading as data packet to a

host computer – If host connection is lost, old readings are overwritten

• Each furnace is monitored at its own frequency– Changed by control packet from the host.


5/11/2012 Bo Sanden, CTU 100

12/7/2012 Bo Sanden, CTU 101

Resource-user threadsAda 83 solution

<<safe>>converter

<<safe>>transmitter

interrupt

read-temp send-DP

receiverfn:

Furnace

• “interrupt” is when a control packet is received for a certain furnace• Furnace tasks use delay and thus rely on built-in scheduling• The solution is rather busy with all the tasks

• Only two Furnace tasks can be active at once:• One using the converter• One using the transmitter

11/5/2012 Bo Sanden, CTU 102

Resource-guard threads

<<safe>>queue

getput

deletesampler

trans-mitter

• The scheduling logic is part of the sampler task• Turned out to be simple enough though

• RTS: Good example of the need to look at dual solutions• With many resource users sharing few resources (and doing little else)

resource-guard threads can work best• The concurrency level is 2

12/7/2012 Bo Sanden, CTU 103

6.5.2 Home heater

• A single task can manage the heating of a single home (5.3)– Sequential-activities task– State represented implicitly in the logic

• Modification:– 5 homes share a fuel line; only 4 can be heated at

once• Each home’s task becomes a resource-user task

– The resources are heating tokens

– The protocol is more complicated than acquire-release

» A long-suffering home can insist on heating

2/21/2012 Bo Sanden, CTU 104

Logic for heating a single homeWait for master switch to be OnWhile system is on:




1. Master switch turned Off2. Motor status changes to Off3. Fuel flow status changes to Off4. Combustion status changes to Off



Allow for cool-down.

5/19/2012 Bo Sanden, CTU 105

Heater as resource-user task type

<<safe>>token-pool

acquire

insist

release

<<safe>> shut-off

forced-off

force-off

hn: Heater

Note: forced-off is a Boolean function

12/7/2012 Bo Sanden, CTU 106

Resource-sharing logic insertedWait for master switch to be OnWhile system is on:


Acquire a token:Call Acquire repeatedly for up to 10 minutes, then InsistKeep monitoring master switch



1. Master switch turned Off2. Motor status changes to Off3. Fuel flow status changes to Off4. Combustion status changes to Off5. Another home needs heating



Release token. Allow for cool-down.

12/7/2012 Bo Sanden, CTU 107

Dual, resource-guard solution?

• Is there a reasonable dual solution?– 4 instances of a resource-guard task type heat could guard the shared

resource

– A task of type check-temp-get-token runs when a home is not heated

• It has 5 instances

• Not resource-guards but necessary in the assembly line

• This could be a 2-station assembly line with multiple servers– But the metaphor of homes traveling the line may be unintuitive

• Instead, we can think of each home as a state machine– unheated, waiting …, and heated are states,

– heat and check-temp are activity tasks

Home state machinemodified from Fig. 6-6

Unheated do / check

temperature

Heated do / heat

Heating need [token available]

Done heating

Waiting for tokendo / keep trying Token received

Heating need [no token]

5/14/12 108Bo Sanden, CTU

• This maps onto a concurrent-activities solution• Each home has:

• A state-machine protected object • An activity task for the superstate

• It gets the home a heat task when needed• There are only 4 heat tasks

• This solution is not optimal for the home heater• but may be in other, similar problems

6.7 Repository problems

• In an assembly line, each item is serviced individually by one resource-guard task after the other

• In other problems, items are collected in a repository and then processed– Often at a different pace and/or collectively

• Example: Weather buoy– Data collected by periodic tasks, reported in batches

• Usually, no dual solution exists– No resource-user thread/task solution

• Elevator12/7/2012 Bo Sanden, CTU 109

Elevator-bank controller

<<protected>>External-requests

External-sampler

Elevator

<<protected>>Internal-requests

Internal-sampler

4/13/2012 Bo Sanden, CTU 110

• Service requests collected• Each elevator consults repositories:

• before stopping at a floor • before continuing

• Separate repositories for requests from floor buttons and from buttons inside each cabin

5/19/2012 Bo Sanden, CTU 111

7. Simultaneous access to shared resources

• Resource-user tasks are surrogates for resource users in the problem– A domain resource user entity has exclusive access to a

resource exactly while its surrogate task holds the corresponding lock

– Examples: Customer, Heater, and Furnace entities/tasks

• Still works if each entity needs 2 or more shared resources at once– But we must defend against deadlock

Deadlock

• Example: – Entity B holds resource R while waiting for resource S, and– Entity C holds S while waiting for T, and – Entity D holds T while waiting for R

• There is a circular wait chain

• Deadlock requirements:– A circular wait chain can form– Sufficient number of entities to populate the wait chain

• In this example, 3 entities, B, C, and D

– Each entity waits indefinitely

5/15/2012 Bo Sanden, CTU 112

10/26/12 113

Wait chain of resources

• R1 R2 ... Rn – such that some entity (Ek) is holding Rk

• while waiting for Rk+1 for k = 1, .. n - 1.

• If the wait chain is circular, there is deadlock:

R1 R2 R3 R4

E4

E1 E2 E3

Deadlock prevention

• Remove one of the requirements:1. Define an order rule, say R < S < T

• R “before” S, etc.• An entity may hold R and wait for S or T,

but may not hold S or T while waiting for R1. etc.

2. So D cannot hold T while waiting for R

1.It is a partial order: antisymmetric & transitive

2. Limit the number of entities3. Make entities give up waiting (after a while)

• This is implemented in the software

5/12/2012 Bo Sanden, CTU 114

7.2.3 Dining philosophersN

E

S

W

F4

F3

F1

F2

N

S

W E

11/2/2012 Bo Sanden, CTU 115

• The wait chains to the right are circular: • A philosopher, say N, may in effect be waiting for himself to release

F4 (or F1)

7.2.3.1 Deadlock prevention in philosopher problem

• Three possible solutions:1. Impose an order rule:

• Require, for example, F1 < F2 < F3 < F4 • Then N isn’t allowed to hold F4 while waiting for F1

– Limit number of philosophers at the table1. 3 philosophers can always eat together

– Eliminate indefinite wait:• Each philosopher yields after waiting a while

11/5/2012 Bo Sanden, CTU 116

Semaphore PO for philosophersprotected type Forksema is -- For a single fork

entry Acquire;

procedure Release;

private

Taken : Boolean := False;

end Forksema;

protected body Forksema is

entry Acquire when not Taken is

begin Taken := True;

end Acquire;

procedure Release is

begin Taken := False;

end Release;

end Forksema;

Sema : array (1 .. Seats) of Forksema; -- One semaphore for each fork

•Typically, instances of a task type Philosopher would call Forksema for each fork.

7/28/2012 Bo Sanden, CTU 117

Monitor package for philosophers• Each philosopher acquires all resources before eating and then releases them

• We can encapsulate all the resource sharing in a monitor package

package body Forks is

protected type Forksema is …; -- Semaphore for a single fork

Sema : array (1 .. Seats) of Forksema; -- Number of philos; assumed > 1

procedure Eat (S : Seat; dinnertime : Duration) is-- The forks are determined by Seat; a philo cannot grab – or release – an arbitrary fork.

-- The fork numbering is a secret of the monitor package

Firstfork : Seat := S; Secondfork : Seat := 1; -- Correct only for S = Seats.

begin

if S < Seats then Secondfork := S + 1; end if; -- Correct forks assigned here

Sema (Firstfork).Acquire; -- Order rule enforced to

Sema (Secondfork).Acquire; -- prevent deadlock

delay dinnertime; -- Eating time in seconds

Sema (Firstfork).Release; -- Release forks in any order

Sema (Secondfork).Release;

end Eat;

end Forks;

11/14/2012 118

More realistic examples of deadlock prevention

• In simple cases, resource-user entities acquire all resources at once and then release them– and then perhaps acquire and release them again, multiple

times– The resource sharing can be encapsulated in a monitor

• In more realistic examples, this is usually impossible:– Automated switchyard– Flexible manufacturing system

11/9/2012 Bo Sanden, CTU 119

2/21/2012 Bo Sanden, CTU 120

7.3.1 Switchyard example

Switch-engine siding

Locomotive siding

Uncoupling-device siding

1

2

3

Freight terminal

4

8

5

6

7

Empties

Ric

hmon

d

Har

rison

burg

Roc

kvill

e

Ann

apol

is

Main line

11/5/12 121

Deadlock prevention in switchyard

• Potential deadlock situation: – An engine going “up” sits on 4-5; another headed “down” sits on

5-6, for example

• Ordering segments from the root up– Engine headed “up” acquires segments as it goes

• Destination sidings are before all others in the order

– Engine heading “down” must acquire its whole path• Must secure segments from the bottom up

• Ordering segments from the top down– Vice versa

• Examples such as this illustrate that the order is partial:– Segments 5-8 and 6-7 have no “before” relationship, for instance

2/21/2012 Bo Sanden, CTU 122

7.3.2 Flexible manufacturing system (FMS)

Storage (Automated storage and retrieval system, ASRS)

Work-station

tool

RI O I I

I I IOO

O

O

O

Work-station

tool

Work-station

tool

Work-station

tool

Work-station

tool

Work-station

tool

R R

R R R

S S S S S S

AGV

AGV

Forklift truck

11/5/2012 Bo Sanden, CTU 123

FMS• The software controls a flexible manufacturing

plant – Each job is completed by machining a part at a series

of workstations.

• Resource management is the main concern: – Each job needs shared resources in different

combinations:• Workstation in- and out-stands, automated guided vehicles

(AGVs), a forklift, etc.

• There is one central computer– And microcomputers at each workstation.

11/5/2012 Bo Sanden, CTU 124

7.3.2.2 Resource-user thread model: Job entities, Job threads

• A thread model based on jobs works because:– Each event in the FMS problem happens to a specific part.

– No event involves two parts.

– No two events in the life of a part are simultaneous.

• Intuition: – Jobs “drive” this model by pursuing their own process plans to completion.

• Not optimal unless the number of jobs in progress is unusually small. – (Many jobs are idle in storage at any given time.)

– Difficult to find the exact concurrency level. • Upper limits can be based on number of stations, AGVs, forklifts, storage stands

• Supports some worthwhile alternative architectures:– A job headed for storage could linger at a storage stand and see if the next

workstation has become available• Suggested by Jessica Deines October 2012

2/21/2012 Bo Sanden, CTU 125

State diagram of job Job created

Workstation assigned

Part extracted from bin

Part placed on storage stand

Part picked by AGV

Part placed on workstation in-stand

Part moved into tool

Part placed on workstation out-stand

Part bumped/finished/scrapped

Part picked by AGV

Part placed on storage stand

Part picked by forklift

Part inserted in bin

Finished/scrapped part removed from system

Workstationassigned

[Part in progress]

Deadlock preventionfor workstation-level resources

• Workstation-level resources include in-stands, tools, and out-stands– The others are transport-level resources

• Deadlock hazard:– Job1 on In-stand1– Job2 in Tool1– Job3 on Out-stand1 headed for In-stand2– Job4 on In-stand2– Job5 in Tool2– Job6 on Out-stand2 headed for In-stand1

• Prevention: – Eliminate the indefinite waiting:

• A job that is done in the tool gets to bump any job still on the out-stand• So Job2 and Job5 do not wait forever

9/29/2012 Bo Sanden, CTU 126

11/5/2012 Bo Sanden, CTU 127

Job-task pseudocode

Get information about first job step while not done loop

Acquire in-stand of workstation for first job stepTravel from bin to storage standFloor : loop

-- Assertion: Job is on out-stand or storage stand, bound for in-stand

Travel from storage/out stand to in-standInform workstation about job-- (Process continues at workstation microprocessor)Wait for job to appear on out-standGet information about next job stepexit Floor loop when doneAttempt to acquire in-stand of workstation for next stepwait for either:

In-stand acquiredor Bumping signal (then exit Floor loop)

end loop FloorAcquire storage standTravel from out-stand to storage standTravel from storage stand to bin

end loop

11/5/2012 Bo Sanden, CTU 128

Bumping in Ada• Bumping is a critical part of any FMS solution• Because the job task is a surrogate for the real job, it

waits for either: In-stand acquiredor Bumping signal

• This becomes an asynchronous select statement:

select Workstation_manager.Request (…, Next_Ptr );

then abortWorkstation_ptr.Clear_Outstand; - - Bumping ordered

end select;exit … when Next_Ptr = null; - - Bump if no in-stand

• (If the request is accepted, it doesn’t matter if Clear_Outstand is also called.)

11/5/2012 Bo Sanden, CTU 129

Deadlock preventionfor transport-level resources

• A Job traveling from storage to workstation acquires and releases resources as follows:

1. Acquire workstation in-stand.

2. Acquire storage stand.

3. Acquire forklift.

4. Release forklift (when part on storage stand).

5. Acquire AGV.

6. Release storage stand (when part on AGV).

7. Release AGV (when part on workstation in-stand).

8. Wait for tool.

9. Release in-stand (when part in tool).

10.Get out-stand (when part done in tool).

11.Release tool.

9/29/2012 Bo Sanden, CTU 130

Locking order

• Order rule:

In-Stand < Storage Stand Storage Stand < ForkliftStorage Stand < AGVOut-Stand < Storage Stand

–A job cannot hold a storage stand and be waiting for an in-stand–A job cannot hold a forklift and be waiting for a storage stand–etc.

• This is built into the logic of the Job task

11/5/2012 Bo Sanden, CTU 131

7.3.2.3 Resource-guard thread model:Workstation tasks

• A dual model may be useful for the workstation-level resources:– FMS can be thought of as a virtual assembly line of workstations.

– There can be 3 jobs at each workstation, so it needs 3 event threads:

• Job_to_In_stand: – Those events that take the job to the in-stand

• Job_in_WS: – Those events that take a job through the workstation

• Job_to_Storage: – Those events that take a job from out-stand to storage (when

necessary)

• Intuitively, each in-stand “drives” the system– It moves one part after the other onto itself as it becomes vacated.

11/5/2012 Bo Sanden, CTU 132

Transport-level resources

• The workstation threads are also the users of transport-level resources: – AGVs, forklift, storage stands– Job_to_In_stand acquires resources to transport a part– Each thread represents part of a job’s life

• So the resource-guard tasks double as resource-users at the transport level

11/5/2012 Bo Sanden, CTU 133

Workstation-task architecture• 3 tasks per workstation:

– Job_to_In_stand repeatedly:• finds a eligible part

• acquires a storage stand, the forklift, an AGV, etc.

• moves the part by operating the forklift and the AGV

• moves the part into the tool

– Job_in_WS repeatedly:• waits for machining to end

• initiates bumping, if necessary

• moves part onto the output stand

• queues the part for the next workstation type, if necessary

– Job_to_Storage repeatedly:• moves the part to storage when it is finished or bumped

• if necessary, dequeues the part and re-enqueues it when in storage

11/5/2012 Dr. Bo Sanden, CTU 134

FMS: Comparison of thread models and designs

• Each architecture follows the basic entity-life model: – The event occurrences are partitioned into threads.

• The job-task and workstation-task solutions both capture the resource contention well:– Tasks represent resource users– Lend themselves to deadlock prevention

• Address the resource contention first!– It deals with deadlock prevention– It often give useful structure to the task architecture

11/5/2012 Dr. Bo Sanden, CTU 135

7.3.2.4 Tasks based on intuitively active objects?

• Intuition: – Every event is caused by an AGV, a forklift, or a workstation.

– They do something to the part• Move it, etc.

– Parts are passively handed over from one to the other• (Usually via queuing)

• One thread per Workstation, one per AGV, one per Forklift. – A Supervisor thread: events to create a job, get initial resources

• Same as in the other models

• Optimal for certain numbers of AGVs, forklifts and workstations. – There can be times when all are busy.

• Becomes involved because of the simultaneous exclusive access– Especially the bumping

(Fig. 7.10)

:AGV- queue

:Storage-stand

:Stand-queue

job2

job1

6a: enqueue

:Forklift-queue

:AGV2: got-AGV

1: remove

3: release

4: conditional-remove

5: got-stand

6b: enqueue

9/6/12 136

11/5/2012 Bo Sanden, CTU 137

ConclusionFuture work

• More, specialized event-thread patterns– Transaction protocol for financial applications

• Things can be tidied up and perhaps formalized– The concurrency level can vary across a problem.

• This is sometimes important if the level is different in some major mode.

– The mapping of resource-guard threads onto concurrent-activity tasks needs elaborated further

12/19/2012 Bo Sanden, CTU 138

References

• L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd ed. Addison-Wesley, 2003.• G. Booch, “Object-oriented development,” IEEE TSE, vol. 12, no. 2, pp. 211-221, Feb. 1986.• J. R. Carter and B. I. Sandén, “Practical uses of Ada-95 concurrency features,” IEEE Concurrency, vol. 6, no. 4,

pp. 47-56, Oct./Dec. 1998.• G. Coulouris, J. Dollimore, T. Kindberg, and G. Blair, Distributed systems: Concepts and Design, 5th Ed., Addison-

Wesley 2012• H. Gomaa, Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison-Wesley, 2000.• D. E. Perry and A. L. Wolf, “Foundations for the Study of Software Architecture,” ACM Software Engineering

Notes, vol. 17, no. 4, pp. 40-52, Oct. 1992.• B. I. Sandén, Software Systems Construction with Examples in Ada, Prentice-Hall 1994.• B. I. Sandén, “Entity-life modeling: Modeling a thread architecture on the problem environment,” IEEE Software,

vol. 20, no. 4, pp. 70-78, July 2003.• B. I. Sandén, Design of Multithreaded Software: The entity-life modeling approach, IEEE Computer Society/Wiley

2011. ISBN 978-0470-87659-6.• B. I. Sandén, “Entity-life modeling: Designing reactive software architectures to the strengths of tasks,” Ada User

Journal, vol. 33, no. 1, pp. 54-61, March 2012.• D. C. Schmidt et al., “Leader/Followers: A Design Pattern for Efficient Multi-Threaded Event Demultiplexing and

Dispatching,” – Tech. report no. wucs-00-29; – Proc. 7th Pattern Languages of Programs Conf., Washington Univ., St. Louis, Mo., 2000

• J.-E. Strömberg, Styrning av LEGO-bilfabrik. Laboration i digital styrning (in Swedish), Linköpings Tekniska Högskola 1991.

Documents

Design of multitask software The entity-life modeling approach Dr. Bo Sandén Colorado Technical University Colorado Springs [email protected] 19 December