1 / 43

IT-606 Embedded Systems (Software)

IT-606 Embedded Systems (Software). S. Ramesh Krithi Ramamritham Kavi Arya KReSIT/ IIT Bombay. Synchronous Models: Motivation S. Ramesh. Concurrency Models . ES are concurrent systems Environment and System evolve simultaneously

jorryn
Download Presentation

IT-606 Embedded Systems (Software)

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. IT-606Embedded Systems(Software) S. Ramesh Krithi Ramamritham Kavi Arya KReSIT/ IIT Bombay

  2. Synchronous Models: MotivationS. Ramesh

  3. Concurrency Models • ES are concurrent systems • Environment and System evolve simultaneously • ES often decomposed into subsystems that evolve concurrently • Concurrent systems are more complex • Model of concurrency varied and often confused • Clear understanding essential

  4. Concurrent Programs • A concurrent program consists of two or more processes • Each process is a sequential program • `threads' or `processes’ • Example: Cobegin x = 5 || y = 10 || z = 23 Coend

  5. Concurrent Execution Concurrent execution involves, • Sequentially executing each process • Interleaved execution model • any process executed at any time • any number of instructions from a process • arbitrary interleaving • No assumption on relative speeds • This is a conceptual model • In reality, simultaneous execution possible • useful for analysis and understanding

  6. Example execution Cobegin x = 5 || y = 10 || z = 23 Coend • x, y and z updated to 5, 10 and 23 respectively • Updation takes place in any order • Not necessarily the textual order • Final result independent of execution order • Not true, in general

  7. Nondeterminism • Same input, different execution leads to different results, in general • Nondeterminism cobegin printf ("Hello world!\\n") || printf ("How are you?\\n") || printf ("What is your name?\\n") coend • What will be the result of execution?

  8. Nondeterminism Some of the Possible results are: • Hello World! How are you? What is your name? • How are you? What is your name? Hello World! • What is your name? Hello World! How are you? Are there any other possibilities?

  9. Another Example cobegin x = 0; x = x + 1; || x = 1; x = x + 1 coend What is the value of x at the end? • 1, 2 ? • 3? • Is 0 possible?

  10. Interleaved Execution How different values possible? • Interleaving of steps of processes • What is a step? • A single statement in the language? • An instruction in the machine language? • It can be anything • Even reading / writing a bit / byte of data • Depends upon the machine

  11. Speed Independence Result of concurrent execution • Depends upon relative speeds of processes (Race Condition) • But this is undesirable, in general • Write programs that compute the same irrespective of relative speed of execution

  12. Non Deterministic Programs • There are cases, when we do not mind indeterminacy • Server responses to client processes • Order of printing of user files • Abstract models (recall lift controller example)

  13. Speed Independence • How to reconcile determinism with concurrency? • Classical approach (discussed earlier) • Synchronous approach ( now)

  14. Classical Approach • Independent Processes • Too restrictive • Communicating Processes • Shared variables and synchronization mechanisms • Test and Set primitives, Semaphores, Monitors • Message Passing • No sharing of variables • Send and receive primitives • Some kind of synchronization mechanism

  15. Atomicity Problem with shared variables concurrency is: • Programmer does not know what the steps are? • Steps would depend upon various factors: machines, schedulers, OS, load etc. • For deterministic behaviour, programmer should specify these steps and execution mechanism ensures that

  16. Atomicity (contd.) • Synchronization mechanisms enable specify these steps • These steps are called atomic steps • No sub-steps - no interleaving • Test-set, semaphores and monitors are high level specification of atomic steps

  17. Atomic steps • Here is another variation - One of the simplest • Programs indicate atomic actions • Specified atomicity can include one or more statements Example: Cobegin < x = 0; % <…> indicates atomic action x = x + 1 > || < x = 0 >; < x = x + 1> Coend What will be the value of x at the end?

  18. Problems with concurrency • Programs will still be non-deterministic! • Due to interleaving of atomic actions from different processes • Careful use of shared variables essential • Programs can be deadlocking. Eg.: P1::P(x); P(y); S1; V(y); V(x) || P2::P(y); P(x); S2; V(x); V(y) • P1 waits for P2, P2 waits for P1 • No progress, circular wait • Deadlock, a new kind of error

  19. Starvation Consider the following problem: y = 1; x = 0 cobegin while (y > 0) {x = x + 1} || y = 0 coend • Will the program terminate ?

  20. Starvation Example • Need not terminate • First process can keep executing • Terminates in practice • Fairness in selection of processes

  21. Conspiracy cobegin P1:: while (x > 0) { await (y =1) do y = 0; S1; y = 1 } || P2:: while (x > 0) { await (y =1) do y = 0; S2; y = 1 } || P3:: while (x > 0) { await (y =1) do y = 0; S3; y = 1 } coend

  22. Message Passing Concurrency Processes • do not share variable • share channels instead • channels carry messages • send and receive actions • asynchronous communication

  23. Message Passing Concurrency • handshake communication • receiver waits till sender sends a message • sender waits when the channel is full • guarded wait actions • Languages like CSP, Promela, Handel-C

  24. Problems • This model is also not free of problems • Deadlock, livelock, conspiracies possible Example: Cobegin P1:: recv m1 from P2; send m2 to P3 || P2:: recv m3 from P3; send m1 to P1 || P3:: recv m2 from P1; send m3 to P2 coend

  25. Synchronization Mechanisms • to ensure determinacy • But still no guarantee on execution • Unpredictability, Deadlocking, Divergence • Naive implementation not suitable for real-time embedded systems • Many proposals to improve the situation

  26. Synchronization Mechanisms • Priorities, specific scheduling mechanisms • But still a lot of problems • Complex task management strategies • Robustness under change of design • It is a very challenging job • Definitely can be avoided for very many embedded systems • Consumer embedded systems, games and toys

  27. Synchronous Model • Alternative to the classical model • reconciles concurrency with determinism • Free of many of the above problems • with Enhanced predictability • More confidence • works very effectively for simple systems • Various Languages employ this • HW description languages (VHDL, Verilog) • Esterel, Lustre, Signal, Statecharts • Handle C

  28. Synchronous Concurrency • A novel model of concurrency • Given a concurrent program cobegin P1 // P2 // P3 Coend • P1, P2 and P3 simultaneously executed! • Execution of each Pi is a series of atomic steps • What is an atomic step?

  29. Synchronous Concurrency • Every step of each process is synchronized with that of other processes • Contrast with classical notion: • steps of different processes are interleaved • One single step of only one process at a time

  30. Example cobegin x = 4 // y = 6 // z = 19 coend • Execution involves one single step in which all the threeassignments are simultaneously executed • How is this executed in the classical model?

  31. Example (contd.) • What about this example? cobegin x = 0 // x = 1 coend • Undefined in the synchronous model • Sharing of variables disallowed • How do processes communicate then?

  32. Process Communication • Through special communication mechanisms • Event-oriented communication • one process generates or causes an event • While other processes waits for consuming the event

  33. Process Communication • Synchrony Hypothesis • Event generation and consumption simultaneous • Example: cobegin emit S(15) // await S(x) coend • Execution involves • emission of S with value 15 by process 1 • absorption of the signal by process 2 with x assigned this value

  34. Process Communication • Communicating partners - various possibilities: • one to one communication • one to many communication: • broadcasting • can there be multiple generators? • Some models allow this (VHDL, Esterel)

  35. Process Communication • Special care for events with different values • Example: cobegin emit S(10) // emit S(15) // await S(x) coend • value of x is 25! - Resolution Function

  36. Absence of events • Synchronous execution is powerful • Since signal emission is simultaneous, absence of signals can be tested! • Absence of a message can not be tested in asynchronous systems • Example: cobegin x = 16 // present not(S) then y = 20 coend

  37. Absence of events • Of course this gives rise to paradoxes: present not(S1) then emit S2 // present not(S2) then emit S1 • More on this later

  38. A notion of time • Synchronous execution defines a sequence of discrete instances • In the first instance, first steps of all processes executed • In the second, second steps of all are executed and so on • Instances can be taken as clock ticks • Execution can be viewed to proceed in a sequence of instances

  39. A notion of time (contd.) • The instances can be triggered from outside • by clock ticks (HW implementation) • periodically or interrupt-driven by program (SW) • This makes the language a real-time language • Processes can count time now! await 4 ticks

  40. Deterministic Execution • Synchronous execution coupled with no sharing of variables • leads to deterministic results • Testing of absence of signals gives rise to some nondeterminism • canbe resolved in some way (more on this later)

  41. Implementation • How to implement synchronous execution? • Hardware implementation: • By multiple functional units with the same clock • Software Implementation: • By compiling away concurrency (Esterel) • concurrency required only for ease of description • can be replaced by sequential code at run time (Esterel) • Advantage: • No run time overhead of tasks and tasks scheduling • More predictable results • More on this later

  42. Summary Classical Concurrency Model • an asynchronous model • No upper-bound on waiting time • No guarantee on execution of atomic actions • Very little control on timing • System behaviour unpredictable, especially under revision • gives serious problems for real-time applications

  43. Summary • Synchronous Model • free of many undesirable features • Given a very brief introduction • Multi-step execution • Communication via broadcasting • Notion of time • Concrete illustration using Esterel later

More Related