Design of multitask software The entity-life modeling approach

1. Design of multitask softwareThe entity-life modeling approach Dr. Bo Sandén Colorado Technical University Colorado Springs bsanden@acm.org 19 December 2012

2. Agenda • Introduction • Tasks and protected objects • State diagramming • ELM concepts • Design patterns based on event threads • Event-thread patterns for resource sharing • 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 Bo Sanden, CTU

3. 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 Bo Sanden, CTU

4. 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 withothers Bo Sanden, CTU

5. 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 Bo Sanden, CTU

6. 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 workingmachine, 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 Bo Sanden, CTU

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

8. 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 Bo Sanden, CTU

9. New tools and materials require new design techniques • 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 Bo Sanden, CTU

10. 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) 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 delaydelay until • Tasks can be periodic: • Samplers, regulators, output generators Bo Sanden, CTU

12. 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 Bo Sanden, CTU

13. 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 Bo Sanden, CTU

14. Interrupt and timing-event handling • Protected procedures can be • interrupt handlers • event handlers called by timing events: protectedbody 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; Bo Sanden, CTU

15. Special-purpose protected objects • Tasks can be surrogates for resources users in the domain • Control of access to shared domain resources: • Semaphoreprotected object • Guards a domain resource • Basic operations: • Acquire • Release • Monitorpackage • Represents a domain resource • Operations on the shared resource encapsulated together with a semaphore • Cannot be a PO Bo Sanden, CTU

16. Semaphore protected objectfor a forklift in a flexible manufacturing system (FMS) protectedForklift_Semaphore is entry Acquire; procedure Release; private Busy : Boolean := False; end Forklift_Semaphore; protected body Forklift_Semaphore is entry Acquire whennot Busy is begin Busy := True; end Acquire; procedure Release is begin Busy := False; end Release; end Forklift_Semaphore; Bo Sanden, CTU

17. Monitorpackage package Forklift_Monitor is procedure Use_Forklift ( … ); end Forklift_Monitor; packagebody Forklift_Monitor is protectedForklift_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; Bo Sanden, CTU

18. 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 Bo Sanden, CTU

19. 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; Bo Sanden, CTU

20. 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 Bo Sanden, CTU

21. Other protected objects Ex.: Leader/followers pattern • Tasks of type C_Serve serve a communication port • They take turns pending on the next message and processing it • A protected object represents the task set • The tasks are queued on entry Join_Set • One task must pend on an event on a handle set. • That task is the leader • After demultiplexing: • it promotes another task in the set, • processes the message, and then • re-joins the task set • [Schmidt et al. 2000] Bo Sanden, CTU

22. 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; Bo Sanden, CTU

23. Pseudo-Ada for C_Serve tasks begin loop Task_Set.Join_Set; --This task is now the leader pend on event on Handle set demultiplex Task_Set.Promote_New_Leader; process message end loop; end;

24. 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 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: selectdelayuntil Next_Reading; thenabort <some computation> endselect; • <some computation> starts. • If not done by Next_Reading, it is aborted. Bo Sanden, CTU

26. General ATC select 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.

27. 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 • toptakes 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 Bo Sanden, CTU

28. Garage door[Sandén 2012] Example from [Bass et al. 2003] Bo Sanden, CTU

29. 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. Bo Sanden, CTU

30. State-diagramming conventions • 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 Bo Sanden, CTU

31. Kinds of activities • Nominal activities: • Example: Apply heat (as in a toaster) • Reduces to 2 actions: heat_on and heat_off • Softwareactivities: • 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) Bo Sanden, CTU

32. Window elevator for a car(referenced later) • 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

33. Car window elevator

34. 4. ELM Concepts (Not in book)

35. Event threads • The eventsof 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 oneevent thread Bo Sanden, CTU

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,

37. Essentialevents • 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 Bo Sanden, CTU

38. 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 Bo Sanden, CTU

39. 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 Bo Sanden, CTU

40. 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. Bo Sanden, CTU

41. 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 Bo Sanden, CTU

42. 1. Partitioning the events per floor 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 • 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 notform an event thread • This is not a legitimate event-thread model Bo Sanden, CTU

43. 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 Bo Sanden, CTU

44. 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 Bo Sanden, CTU

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-occurif: • You can construct an arbitrarily short time interval where each may have a different event occurrence

46. Optimal thread models. Concurrency levels • A thread model is optimalif 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 levelof 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 notrequire that all thread models be optimal

47. 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 Bo Sanden, CTU

48. Long-lived threads • A long-livedthread 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-livedthreads 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 Bo Sanden, CTU

49. 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 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 Bo Sanden, CTU