1. General Language Characteristics

2. Synchronous vs. asynchronous languages • 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“.

3. 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.

4. Properties of processes • Number of processes • Static (sufficient if each process models a piece of HW) • dynamic (dynamically changed hardware architecture?) • Nested declaration of processes or all declared at the same level • Different techniques for process creation Elaboration in the source code, explicit fork and join, process creation calls  StateCharts comprises a static number of processes, nested declaration of processes, and process creation through elaboration in the source code.

5. Communication paradigms • Message passing • Non-blocking communicationSender does not have to wait until message has arrived; potential problem: buffer overflow • Blocking communication, rendez-vous-based communicationSender will wait until receiver has received message • Extended rendez-vousExplicit acknowledge from receiver required. Receiver can do checking before sending acknowledgement.

6. Communication paradigms (2) • Shared memory • Variables accessible to several tasks • Critical sections = sections at which exclusive access to some resource r must be guaranteed.  StateCharts uses shared memory for communication between processes.

7. Specifying timing • 4 types of timing specs required [Burns, 1990]: • Measure elapsed time • Check, how much time has elapsed since last call • Means for delaying processes • Possibility to specify timeouts • We would like to be in a certain state only a certain maximum amount of time. • Methods for specifying deadlines • With current languages not available or specified in separate control file.  StateCharts comprises a mechanism for specifying timeouts. Other types of timing specs are not supported.

8. 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.

9. SDL

10. 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 1980 • Updates in 1984, 1988, 1992, 1996 and 1999

11. 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.

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

13. 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:

14. Petri Nets

15. Petri nets • Introduced in 1962 by Carl Adam Petri in his PhD thesis. • Focus on modeling causal dependencies; • no global synchronization assumed (message passing only). • Key elements: • Conditions : Either met or no met. • Events : May take place if certain conditions are met. • Flow relation : Relates conditions and events. • Conditions, events and the flow relation form a bipartite graph (graph with two kinds of nodes).

16. Example: Synchronization at single track rail segment „Preconditions“ event flow relation condition

17. Playing the „token game“ use normal view mode!

18. Conflict for resource „track“

19. Applications • Modeling of resources; • modeling of of mutual exclusion; • modeling of synchronization.

20. Evaluation • Pros: • Appropriate for distributed applications, • Well-known theory for formally proving properties, • Initially a quite bizarre topic, but now accepted due to increasing number of distributed applications. • Cons (for the nets presented) : • problems with modeling timing, • no programming elements, • no hierarchy. back to full screen mode