DSL Design DSL Design Jumps/GOTOs Control flow in DSLs A jump - PowerPoint PPT Presentation

DSL Design DSL Design • Jumps/GOTOs • Control flow in DSLs • A jump transfers control to a specified program point A j f l ifi d i • We will study a number of alternatives • A jump has typical the form goto L; and transfer the control − traditional sequencers: to program point L , which is a label − sequential q − conditional if (E 1 ) C 1 − iterative else { − jumps, low-level sequencers to transfer control C 2 goto X; − escapes, sequencers to transfer control out of commands and } procedures C 3 ; − exceptions, sequencers to signal abnormal situations while (E 2 ) { C 4 ; C 4 ; X: C 5 } / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 0 3-1-2011 PAGE 1 DSL Design DSL Design • Unrestricted jumps lead to spaghetti code, thus hard to • A jump out of a block must destroy the local j y understand, see nderstand see variables http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF • Jumps out of a procedure should lead to destroying • Most (programming) languages support gotos • Most (programming) languages support gotos local variables and termination of procedure local variables and termination of procedure activation • Some languages have restrictions: • jumps out of a recursive procedure is semantically • • the jump goto L; is legal only within the scope of L the jump goto L; is legal only within the scope of L even more complicated − jumps within a block − jumps from a block to an enclosing one − jumps into a block from outside is not allowed • Jumps introduce unwanted complexity in the Jumps introduce unwanted complexity in the semantics of languages / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 2 / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 3

DSL Design DSL Design • An escape is a sequencer that terminates the • Exceptions are a mechanism to deal with abnormal execution of a textually enclosing command or situations: procedure • arithmetic operation overflows • break sequencer to break loops • uncompleted input/output operations uncompleted input/output operations • return sequencer to break loops and end procedures • Exceptions take of two things: • Escapes are restricted so that control cannot be p g Escapes are restricted so that control cannot be transfer out of procedures • error handling • controlled termination of flow of control / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 4 3-1-2011 PAGE 5 DSL Design DSL Design • Code that detects an abnormal situation throws an • Concurrency in DSLs? y exception • program design becomes more complex • the exception can be caught in another part of the • testing becomes less effective • historically, improvement of efficiency via • historically improvement of efficiency via program program − multiprogramming systems, usage of idle resources • programmer have control over exceptions and handling • currently, end of Moore’s law, efficiency gain via of it − multi-core processors m lti core processors / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 6 / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 7

DSL Design DSL Design • Problems with concurrency: nondeterminism • A sequential process is a totally ordered set of steps y • sequential programs are deterministic • each step is a change of state • collateral and nondeterministic conditional commands may • A sequential program specifies the state changes of introduce unpredictability in sequential programs a sequential process ti l − compiler is free to determine the order of execution − different compilers may lead to different behavior • A concurrent program specifies the possible state changes of 2 or more sequential processes g q p • A concurrent program is genuinely nondeterministic even for A t i i l d t i i ti f a specific compiler − incorrect concurrent programs may behave correctly in general, but have sometimes unpredictable behavior p / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 8 3-1-2011 PAGE 9 DSL Design DSL Design • Problems with concurrency: speed dependence • Problems with concurrency: deadlock y y • sequential programs are speed-independent because • Deadlock means that processes are unable to make progress correctness does not depend on execution speed because of mutually incompatible demands for resources • concurrent programs are speed-dependent − mutual exclusion : a process may be given exclusive access to p y g concurrent programs are speed dependent resources − behavior depends on the relative speed at which its constituent − incremental acquisition : a process holds previously acquired sequential processes run resource while waiting for new resources − if absolute speeds are considered, outside world, we have real- p , , − no preemption : resources cannot be removed from a process time behavior until it voluntarily releases them − if the outcome is speed-dependent, there is a race condition − circular waiting : a cycle of resources or processes in which each process is waiting for resources that are held by the next process process is waiting for resources that are held by the next process in the cycle / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 10 / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 11

DSL Design DSL Design • Problems with concurrency: starvation • Sequential and collateral commands do not allow y • A concurrent program has the liveness property if it is simultaneously execution of commands guaranteed that every process will make some progress over • The parallel command “ B || C ” indicates that B and a sufficiently long period of time C may executed simultaneously or arbitrarily C may executed simultaneously or arbitrarily − Free of deadlock interleaved − Fair scheduling • Fair scheduling means that no process needing a resource is g p g indefinitely prevented from obtaining it / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 12 3-1-2011 PAGE 13 DSL Design DSL Design • Competing processes • Process interactions: • Commands B and C are competing if they need exclusive • Independent processes: access to the same resource r − commands B and C are independent if the execution of B has no − Let B be the sequence B 1 ; B 2 ; B 3 effect on the execution of C , and vice versa − Let C be the sequence C 1 ; C 2 ; C 3 L t b th − concurrent composition of independent processes is − B 1 , C 1 , B 3 , C 3 are independent, none need r deterministic − B 2 and C 2 both need r , so they cannot take place simultaneously, they are critical section wrt r they are critical section wrt r − B || C may be executed as: − …; B 2 ; … ; C 2 ; … − …; C 2 ; … ; B 2 ; … − but not as …; B 2 ||C 2 ; … / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 14 / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 15

DSL Design DSL Design • • Communicating processes Concurrency primitives g • P Process until now was a flow of control through a program til fl f t l th h • let B be the sequence B 1 ; B 2 ; B 3 • a conventional, heavyweight, process is a program, which involves: • let C be the sequence C 1 ; C 2 ; C 3 − an address space • there is communication from B to C if B produces data that − allocation of main storage, there is communication from B to C if B 2 produces data that allocation of main storage, − share of CPU time C 2 consumes, so B 2 must end before C 2 starts − access to files, devices, etc. • Thus B || C has the same behavior as B; C • context switching from one process to another involves a lot of time • a thread is a lightweight alternative th d i li ht i ht lt ti • Processes B and C intercommunicate if there is − flow of control through a program without computational resources communication in both directions: − switching of threads involves swapping of content of working switching of threads involves swapping of content of working − B || C yields numerous outcomes || C i ld t registers / Faculteit Wiskunde en Informatica / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 16 3-1-2011 PAGE 17 DSL Design DSL Design • Process creation and control • Concurrency primitives for process creation and control • abstract operations for competition in order to make the abstract operations for competition in order to make the • create a new child process critical sections disjoint in time • load program code to be executed by a process − acquire(r) to gain exclusive access to resource r • start execution of a process − relinquish(r) to give up exclusive access relinquish(r) to give up exclusive access • suspend execution of a process − if resource r is already allocated, acquire(r) blocks the • resume execution of a (suspended) process process it calls it − if resource r is freed, processes waiting for access are • let a process stop at the end of its execution unblocked and rescheduled unblocked and rescheduled • let the creator wait for the process to stop • abstract operations for (synchronous) communication • destroy a stopped process, freeing resources − transmit(m) called by a sender to send m − receive(m) called by a receiver to wait for m receive(m) called by a receiver to wait for m • create , load , start are combined into fork − asynchronous communication via broadcasting • wait and destroy into join / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 18 / Faculteit Wiskunde en Informatica 3-1-2011 PAGE 19