1 / 20

General Language Characteristics

General Language Characteristics. 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.

ezhno
Download Presentation

General Language Characteristics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related