Some general properties of languages 1. Synchronous vs. asynchronous languages (1)

1. Some general properties of languages1. Synchronous vs. asynchronous languages (1) • Description of several processes in many languages non-deterministic:The order in which executable tasks are executed is not specified (may affect result). • Synchronous languages: based on automata models. • „Synchronous languages aim at providing high level, modular constructs, to make the design of such an automaton easier [Halbwachs]. • Synchronous languages describe concurrently operating automata. „.. when automata are composed in parallel, a transition of the product is made of the "simultaneous" transitions of all of them“.

2. Some general properties of languages1. Synchronous vs. asynchronous languages (2) • Synchronous languages implicitly assume the presence of a (global) clock. Each clock tick, all inputs are considered, new outputs and states are calculated and then the transitions are made. • This requires a broadcast mechanism for all parts of the model. • Idealistic view of concurrency. • Has the advantage of guaranteeing deterministic behavior. •  StateCharts is a synchronous language.

3. Some general properties of languages2. Properties of processes (1) • Number of processesstatic;dynamic (dynamically changed hardware architecture?) • Nesting: • Nested declaration of processesprocess {process {process {}}} • or all declared at the same levelprocess { … }process { … }process { … }

4. Some general properties of languages2. Properties of processes (2) • Different techniques for process creation • Elaboration in the source (c.f. ADA, below)declare process P1 … • explicit fork and join (c.f. Unix)id = fork(); • process creation callsid = create_process(P1); •  StateCharts comprises a static number of processes, nested declaration of processes, and process creation through elaboration in the source.

5. Some general properties of languages3. Communication paradigms (1) • Message passing • Non-blocking communicationSender does not have to wait until message has arrived; potential problem: buffer overflow … send () … … receive () …

6. Some general properties of languages3. Communication paradigms (2) • Blocking communication,rendez-vous-based communicationSender will wait until receiver hasreceived message … send () … … receive () …

7. Some general properties of languages3. Communication paradigms (2) • Extended rendez-vousExplicit acknowledge from receiverrequired. Receiver can do checking before sending acknowledgement. … send () … … receive () … ack …

8. Some general properties of languages3. Communication paradigms (4) • Shared memoryVariables accessible to several tasksPotential race conditions (inconsistent results possible) Critical sections = sections at which exclusive access to resource r (e.g. shared memory) must be guaranteed. process a { .. P(S) //obtain lock .. // critical section V(S) //release lock} process b { .. P(S) //obtain lock .. // critical section V(S) //release lock} Race-free access to shared memory protected by S possible  StateCharts uses shared memory for communication between processes.

9. t t Some general properties of languages 4. Specifying timing (1) • 4 types of timing specs required [Burns, 1990]: • Measure elapsed timeCheck, how much time has elapsed since last call ? execute • Means for delaying processes

10. t Some general properties of languages 4. Specifying timing (2) • Possibility to specify timeoutsStay in a certain state a maximum time. • Methods for specifying deadlinesNot available or in separate control file. execute  StateCharts comprises a mechanism for specifying timeouts. Other types of timing specs not supported.

11. Properties of specification languages5. Using non-standard I/O devices - • Direct access to switches, displays etc; • No protection required; OS can be much faster than for operating system with protection. •  No support in standard StateCharts. •  No particular OS support anyhow.

12. SDL • Language designed for specification of distributed systems. • Dates back to early 70s, • Formal semantics defined in the late 80s, • Defined by ITU (International Telecommunication Union): Z.100 recommendation in 1980Updates in 1984, 1988, 1992, 1996 and 1999

13. SDL • Provides textual and graphical formats to please all users, • Just like StateCharts, it is based on the CFSM model of computation; each FSM is called a process, • However, it uses message passing instead of shared memory for communications, • SDL supports operations on data.

14. SDL-representation of FSMs/processes state input output

15. Operations on data • Variables can be declared locally for processes. • Their type can be predefined or defined in SDL itself. • SDL supports abstract data types (ADTs). Examples:

16. Communication among SDL-FSMs • Communication between FSMs (or „processes“) is based on message-passing, assuming a potentially indefinitely large FIFO-queue. • Each process fetches next entry from FIFO, • checks if input enables transition, • if yes: transition takes place, • if no: input is ignored (exception: SAVE-mechanism).

17. Process interaction diagrams • Interaction between processes can be described in process interaction diagrams (special case of block diagrams). • In addition to processes, these diagrams contain channels and declarations of local signals. • Example: ,

18. Counter TO OFFSPRING CounterVia Sw1 Designation of recipients • Through process identifiers:Example: OFFSPRING represents identifiers of processes generated dynamically. • Explicitly:By including the channel name. • Implicitly:If signal names imply channel names (B  Sw1)

19. Hierarchy in SDL • Process interaction diagrams can be included in blocks. The root block is called system. Processes cannot contain other processes, unlike in StateCharts.

20. Timers • Timers can be declared locally. Elapsed timers put signal into queue (not necessarily processed immediately). • RESET also removes timer signal from queue.

21. Additional language elements • SDL includes a number of additional language elements, like • procedures • creation and termination of processes • advanced description of data

22. Application: description of network protocols

23. Larger example: vending machine Machine° selling pretzels, (potato) chips, cookies, and doughnuts: accepts nickels, dime, quarters, and half-dollar coins. Not a distributed application. ° [J.M. Bergé, O. Levia, J. Roullard: High-Level System Modeling, Kluwer Academic Publishers, 1995]

24. Overall view of vending machine

25. p DecodeRequests

26. ChipHandler no yes yes no

27. Versions and tools • SDL-88 • SDL-92: object orientation added • SDL-96 • SDL-2000: Extended graphical support;processes and blocks becoming replaced by agents. • Tools for connecting to MSCs (see below) • Tools for connecting to UML (see below) • Tools for translation to CHILL. • Information: www.sdl-forum.org

28. Evaluation • Excellent for distributed applications(was used to specify ISDN), • Commercial tools available from SINTEF, Telelogic, Cinderella (//www.cinderella.dk). • Not necessarily deterministic(order, in which FSMs are reading input is unknown) no synchronous language, • Implementation requires bound for the maximum length of FIFOs; may be very difficult to compute, • Timer concept adequate just for soft deadlines, • Limited way of using hierarchies, • Limited programming language support, • No description of non-functional properties.

29. Summary • General language properties • Synchronous vs. asynchronous languages • Properties of processes • Communication • Timing • Access to special I/O devices • SDL • Representation of processes • Communication & block diagrams • Timers and other language elements • Example: Vending machine • Versions and evaluation