The Esterel Language. The Esterel Version. Basic Ideas of Esterel

Size: px
Start display at page:

Download "The Esterel Language. The Esterel Version. Basic Ideas of Esterel"

Transcription

1 The Synchronous Language Esterel OMS W Prof. Stephen. Edwards Fall 2002 olumbia University epartment of omputer Science The Esterel Language eveloped by Gérard erry starting 1983 Originally for robotics applications Imperative, textual language Synchronous model of time like that in digital circuits oncurrent eterministic Simple Example The specification: The output O should occur when inputs and have both arrived. The input should restart this behavior. First Try: n FSM The Esterel Version The Esterel Version / / / / / module O: input,, ; output O; await await ; emit O each Esterel programs built from modules Each module has an interface of input and output signals module O: input,, ; output O; await await ; emit O each...each statement implements reset await waits for the next cycle where its signal is present /O module module runs the two awaits in parallel /O /O Much simpler since language includes notions of signals, waiting, and reset. The Esterel Version module O: input,, ; output O; await await ; emit O each module Parallel terminates when all its threads have Emit O makes signal O present when it runs asic Ideas of Esterel Imperative, textual language oncurrent ased on synchronous model of time: Program execution synchronized to an external clock Like synchronous digital logic Suits the cyclic executive approach Two types of statements: ombinational statements, which take zero time (execute and terminate in same instant, e.g., emit) Sequential statements, which delay one or more cycles (e.g., await) Uses of Esterel Wristwatch anonical example eactive, synchronous, hard real-time ontrollers, e.g., for communication protocols vionics Fuel control system Landing gear controller Other user interface tasks Processor components (cache controller, etc.)

2 dvantages of Esterel Model of time gives programmer precise timing control oncurrency convenient for specifying control systems ompletely deterministic Guaranteed: no need for locks, semaphores, etc. Finite-state language Easy to analyze Execution time predictable Much easier to verify formally menable to both hardware and software implementation isadvantages of Esterel Finite-state nature of the language limits flexibility No dynamic memory allocation No dynamic creation of processes Little support for handling data; limited to simple decision-dominated controllers Synchronous model of time can lead to overspecification Semantic challenges: voiding causality violations often difficult ifficult to compile Limited number of users, tools, etc. Esterel s Model of Time The standard S model (e.g., Java s) is asynchronous: threads run at their own rate. Synchronization is through calls to wait() and notify(). Esterel s model of time is synchronous like that used in hardware. Threads march in lockstep to a global clock. lock tick Time Signals asic Esterel Statements Simple Example Esterel programs communicate through signals These are like wires Each signal is either present or absent in each cycle an t take multiple values within a cycle Presence/absence not held between cycles roadcast across the program ny process can read or write a signal emit S Make signal S present in the current cycle signal is absent unless emitted in that cycle. Stop for this cycle and resume in the next. present S then s 1 else s 2 un s 1 immediately if signal S is present in the current cycle, otherwise run s 2 module Example1: output,, ; emit ; present then emit ; ; emit module Signal oherence ules Each signal is only present or absent in a cycle,never both ll writers run before any readers do Thus present else emit is an erroneous program. (eadlocks.) The Esterel compiler rejects this program. dvantage of Synchrony Easy to regulate time Synchronization is free (e.g., no akers algorithm) Speed of actual computation nearly uncontrollable llows function and timing to be specified indepently Makes for deterministic concurrency Explicit control of before after at the same time Time an e ontrolled Precisely This guarantees every 60th S an M is emitted every 60 S do emit M every invokes its body every 60th S emit takes no time (cycles) S S S S S M M

3 The Operator Groups of statements separated by run concurrently and terminate when all groups have terminated emit ; ; emit ; ; emit ; ; emit ; emit E E ommunication Is Instantaneous signal emitted in a cycle is visible immediately ; emit ; ; emit ; present then emit idirectional ommunication Processes can communicate back and forth in the same cycle ; emit ; present then emit ; ; emit ; present then emit oncurrency and eterminism Signals are the only way for concurrent processes to communicate Esterel does have variables, but they cannot be shared Signal coherence rules ensure deterministic behavior Language semantics clearly defines who must communicate with whom when The wait Statement The await statement waits for a particular cycle await S waits for the next cycle in which S is present emit ; ; ; emit await ; emit The wait Statement wait normally waits for a cycle before beginning to check await immediate also checks the initial cycle emit ; ; ; emit await immediate ; emit Loops Esterel has an infinite statement ule: body cannot terminate instantly Needs at least one, await, etc. an t do an infinite amount of work in a single cycle emit ; ; ; emit Loops and Synchronization Instantaneous nature of s plus await provide very powerful synchronization mechanisms await 60 S; emit M S S S S S M M Preemption Often want to stop doing something and start doing something else E.g., trl- in Unix: stop the currently-running program Esterel has many constructs for handling preemption

4 The bort Statement The bort Statement Strong vs. Weak Preemption asic preemption mechanism General form: statement when condition uns statement to completion. If condition ever holds, terminates immediately. ; ; emit when ; emit Normal Termination borted termination borted termination; emit preempted Normal Termination not checked in first cycle (like await) Strong preemption: The body does not run when the preemption conditionholds The previous example illustrated strong preemption Weak preemption: The body is allowed to run even when the preemptioncondition holds, but is terminated thereafter weak implements this in Esterel Strong vs. Weak bort Strong vs. Weak Preemption The Trap Statement Strong emit does not run ; ; emit ; when ; emit Weak emit runs weak ; ; emit ; when ; emit Important distinction Something may not cause its own strong preemption Erroneous ; emit when OK weak ; emit when Esterel provides an exception facility for weak preemption Interacts nicely with concurrency ule: outermost trap takes precedence The Trap Statement Nested Traps The Susp Statement trap T in ; emit ; ; exit T await ; emit trap; emit Normal termination from first process Emit also runs Second process allowed to run even though first process has exited trap T1 in trap T2 in exit T1 exit T2 ; emit ; emit Outer trap takes precedence; control transferred directly to the outer trap statement. emit not allowed to run. Preemption (, trap) terminate something, but what if you want to resume it later? Like the unix trl-z Esterel s susp statement s the execution of a group of statements Only strong preemption: statement does not run when condition holds

5 The Susp Statement susp emit ; ; when prevents from being emitted here; resumed next cycle delays emission of by one cycle ausality Unfortunate side-effect of instantaneous communication coupled with the single valued signal rule Easy to write contradictory programs, e.g., present else emit ; emit when present then nothing ; emit These sorts of programs are erroneous; the Esterel compiler refuses to compile them. ausality an be very complicated because of instantaneous communication For example, this is also erroneous ; emit when ; present then emit Emission of indirectly causes emission of ausality efinition has evolved since first version of the language Original compiler had concept of potentials Static concept: at a particular program point, which signals could be emitted along any path from that point Latest definition based on constructive causality ynamic concept: whether there s a guess-free proof that concludes a signal is absent ausality Example emit ; present then emit ; present else emit ; ed statements reachable onsidered erroneous under the original compiler fter emit runs, there s a static path to emit Therefore, the value of cannot be decided yet Execution procedure deadlocks: program is bad ausality Example emit ; present then emit ; present else emit ; onsidered acceptable to the latest compiler ed statements reachable fter emit runs, it is clear that cannot be emitted because s presence runs the then branch of the second present declared absent, both present statements run ompiling Esterel Semantics of the language are formally defined and deterministic It is the responsibility of the compiler to ensure the generated executable behaves correctly w.r.t. the semantics hallenging for Esterel ompilation hallenges oncurrency Interaction between exceptions and concurrency Preemption esumption (, await, etc.) hecking causality eincarnation Loop restriction prevents most statements from executing more than once in a cycle omplex interaction between concurrency, traps, and s allows certain statements to execute twice or more utomata-ased ompilation Key insight: Esterel is a finite-state language Each state is a set of program counter values where the program has d between cycles Signals are not part of these states because they do not hold their values between cycles Esterel has variables, but these are not considered part of the state

6 utomata ompiler Example utomata ompiler Example utomata ompilation onsidered emit ; await ; emit ; void tick() { static int s = 0; = = 0; switch (s) { case 0: = 1; s = 1; break; case 1: if () { = 1; s = 0; break; emit ; emit ; await ; emit ; present E then emit switch (s) { case 0: =1; =1; s=1; break; case 1: if () { =1; if (E) =1; s=2; break; case 2: Very fast code (Internal signaling can be compiled away) an generate a lot of code because concurrency can cause exponential state growth n-state machine interacting with another n-state machine can produce n 2 states Language provides input constraints for reducing states these inputs are mutually exclusive relation # # ; if this input arrives, this one does, too relation => E; utomata ompilation Not practical for large programs Theoretically interesting, but don t work for most programs longer than 1000 lines ll other techniques produce slower code Netlist-ased ompilation Key insight: Esterel programs can be translated into oolean logic circuits Netlist-based compiler: Translate each statement into a small number of logic gates, a straightforward, mechanical process Generate code that simulates the netlist Netlist Example emit ; emit ; await ; emit ; present E then emit Entry E Exit Netlist ompilation onsidered Scales very well Netlist generation roughly linear in program size Generated code roughly linear in program size Good framework for analyzing causality Semantics of netlists straightforward onstructive reasoning equivalent to three-valued simulation Terribly inefficient code Lots of time wasted computing irrelevant values an be hundreds of time slower than automata Little use of conditionals Netlist ompilation urrently the only solution for large programs that appear to have causality problems Scalability attractive for industrial users urrently the most widely-used technique ontrol-flow Graph-ased Key insight: Esterel looks like a imperative language, so treat it as such Esterel has a fairly natural translation into a concurrent control-flow graph Trick is simulating the concurrency oncurrent instructions in most Esterel programs can be scheduled statically Use this schedule to build code with explicit context switches in it

7 Overview Translate every dd Threads every do await ; emit ; present then emit ; present then emit ; 0 t 1 if ((s0 & 3) == 1) { if (S) { s3 = 1; s2 = 1; s1 = 1; else if (s1 >> 1) s1 = 3; else { if ((s3 & 3) == 1) { s3 = 2; t3 = L1; else { t3 = L2; Esterel oncurrent Sequential code Source FG FG every do await ; emit ; present then emit ; present then emit ; every do await ; emit ; present then emit ; present then emit ; Split at Pauses dd ode etween Pauses Translate Second Thread every do await ; emit ; present then emit ; present then emit ; every do await ; emit ; present then emit ; present then emit ; every do await ; emit ; present then emit ; present then emit ; Finished Translating dd epencies and Schedule un First Node every do await ; emit ; present then emit ; present then emit ; every do await ; emit ; present then emit ; present then emit ;

8 un First Part of Left Thread ontext Switch un ight Thread ontext Switch Finish Left Thread ompleted Example 0 t 1 0 t 1 0 t 1 ontrol-flow pproach onsidered Scales as well as the netlist compiler, but produces much faster code, almost as fast as automata Not an easy framework for checking causality Static scheduling requirement more restrictive than netlist compiler This compiler rejects some programs the others accept Only implementation hiding within Synopsys oentric System Studio. Will probably never be used industrially. See my recent IEEE Transactions on omputer-ided esign paper for details What To Understand bout Esterel Synchronous model of time Time divided into sequence of discrete instants Instructions either run and terminate in the sameinstant or explicitly in later instants Idea of signals and broadcast Variables that take exactly one value each instant and don t persist oherence rule: all writers run before any readers ausality Issues ontradictory programs How Esterel decides whether a program is correct What To Understand bout Esterel ompilation techniques utomata: Fast code, oesn t scale Netlists: Scales well, Slow code, Good for causality ontrol-flow: Scales well, Fast code, ad at causality

A Simple Example. The Synchronous Language Esterel. A First Try: An FSM. The Esterel Version. The Esterel Version. The Esterel Version

A Simple Example. The Synchronous Language Esterel. A First Try: An FSM. The Esterel Version. The Esterel Version. The Esterel Version The Synchronous Language Prof. Stephen. Edwards Simple Example The specification: The output O should occur when inputs and have both arrived. The R input should restart this behavior. First Try: n FSM

More information

Using and Compiling Esterel

Using and Compiling Esterel Using and Compiling Esterel Stephen A. Edwards Columbia University Department of Computer Science sedwards@cs.columbia.edu http://www.cs.columbia.edu/ sedwards/ Memocode Tutorial, July 11, 2005 The Esterel

More information

Esterel and the Synchronous Approach

Esterel and the Synchronous Approach Esterel and the Synchronous Approach Stephen A. Edwards Columbia University April 2009 The Big Picture The Digital Approach Discretize value to completely eliminate noise The Synchronous Approach Discretize

More information

EE382N.23: Embedded System Design and Modeling

EE382N.23: Embedded System Design and Modeling EE382N.23: Embedded System Design and Modeling Lecture 3 Language Semantics Andreas Gerstlauer Electrical and Computer Engineering University of Texas at Austin gerstl@ece.utexas.edu Lecture 3: Outline

More information

ESUIF: An Open Esterel Compiler

ESUIF: An Open Esterel Compiler ESUIF: An Open Esterel Compiler Stephen A. Edwards Department of Computer Science Columbia University www.cs.columbia.edu/ sedwards Not Another One... My research agenda is to push Esterel compilation

More information

Synchronous Languages Lecture 07

Synchronous Languages Lecture 07 Synchronous Languages Lecture 07 Prof. Dr. Reinhard von Hanxleden Christian-Albrechts Universität Kiel Department of Computer Science Real-Time Systems and Embedded Systems Group 27 May 2015 Last compiled:

More information

Compiling Esterel into Sequential Code

Compiling Esterel into Sequential Code ompiling Esterel into Sequential ode Stephen A. Edwards Advanced Technology Group, Synopsys 700 East Middlefield Road Mountain View, alifornia 94043 4033 sedwards@synopsys.com Abstract Embedded real-time

More information

Introduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, s

Introduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, s Pascal Raymond, Verimag-CNRS Introduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, sequential style (i.e.

More information

The Esterel language

The Esterel language Pascal Raymond, Verimag-CNRS Introduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, sequential style (i.e.

More information

Last Time. Introduction to Design Languages. Syntax, Semantics, and Model. This Time. Syntax. Computational Model. Introduction to the class

Last Time. Introduction to Design Languages. Syntax, Semantics, and Model. This Time. Syntax. Computational Model. Introduction to the class Introduction to Design Languages Prof. Stephen A. Edwards Last Time Introduction to the class Embedded systems Role of languages: shape solutions Project proposals due September 26 Do you know what you

More information

Language Extensions. present [C and not pre(a or B or C)] then p else q end

Language Extensions. present [C and not pre(a or B or C)] then p else q end A Language Extensions The full Esterel V5 language includes the Kernel Esterel primitives and derived statements whose semantics are given by structural expansion into the primitives. The full language

More information

Concurrency. Glossary

Concurrency. Glossary Glossary atomic Executing as a single unit or block of computation. An atomic section of code is said to have transactional semantics. No intermediate state for the code unit is visible outside of the

More information

CHAPTER 6: PROCESS SYNCHRONIZATION

CHAPTER 6: PROCESS SYNCHRONIZATION CHAPTER 6: PROCESS SYNCHRONIZATION The slides do not contain all the information and cannot be treated as a study material for Operating System. Please refer the text book for exams. TOPICS Background

More information

Chapter 5: Synchronization 1

Chapter 5: Synchronization 1 1 Start of Lecture: January 25, 2014 2 Reminders Assignment 1 is due this Friday at 6:00 p.m. Couple comments about Exercise 1: Thought questions: be honest and sincere about questions you have while reading;

More information

A Deterministic Concurrent Language for Embedded Systems

A Deterministic Concurrent Language for Embedded Systems A Deterministic Concurrent Language for Embedded Systems Stephen A. Edwards Columbia University Joint work with Olivier Tardieu SHIM:A Deterministic Concurrent Language for Embedded Systems p. 1/30 Definition

More information

Reinhard v. Hanxleden 1, Michael Mendler 2, J. Aguado 2, Björn Duderstadt 1, Insa Fuhrmann 1, Christian Motika 1, Stephen Mercer 3 and Owen Brian 3

Reinhard v. Hanxleden 1, Michael Mendler 2, J. Aguado 2, Björn Duderstadt 1, Insa Fuhrmann 1, Christian Motika 1, Stephen Mercer 3 and Owen Brian 3 Sequentially Constructive Concurrency * A conservative extension of the Synchronous Model of Computation Reinhard v. Hanxleden, Michael Mendler 2, J. Aguado 2, Björn Duderstadt, Insa Fuhrmann, Christian

More information

CSC Operating Systems Spring Lecture - XII Midterm Review. Tevfik Ko!ar. Louisiana State University. March 4 th, 2008.

CSC Operating Systems Spring Lecture - XII Midterm Review. Tevfik Ko!ar. Louisiana State University. March 4 th, 2008. CSC 4103 - Operating Systems Spring 2008 Lecture - XII Midterm Review Tevfik Ko!ar Louisiana State University March 4 th, 2008 1 I/O Structure After I/O starts, control returns to user program only upon

More information

Models of concurrency & synchronization algorithms

Models of concurrency & synchronization algorithms Models of concurrency & synchronization algorithms Lecture 3 of TDA383/DIT390 (Concurrent Programming) Carlo A. Furia Chalmers University of Technology University of Gothenburg SP3 2016/2017 Today s menu

More information

A Deterministic Concurrent Language for Embedded Systems

A Deterministic Concurrent Language for Embedded Systems A Deterministic Concurrent Language for Embedded Systems Stephen A. Edwards Columbia University Joint work with Olivier Tardieu SHIM:A Deterministic Concurrent Language for Embedded Systems p. 1/38 Definition

More information

Concurrency, Mutual Exclusion and Synchronization C H A P T E R 5

Concurrency, Mutual Exclusion and Synchronization C H A P T E R 5 Concurrency, Mutual Exclusion and Synchronization C H A P T E R 5 Multiple Processes OS design is concerned with the management of processes and threads: Multiprogramming Multiprocessing Distributed processing

More information

Removing Cycles in Esterel Programs

Removing Cycles in Esterel Programs Removing Cycles in Esterel Programs Dissertation zur Erlangung des akademischen Grades Doktor der Naturwissenschaften (Dr. rer. nat.) der Technischen Fakultät der Christian-Albrechts-Universität zu Kiel

More information

ECL: A SPECIFICATION ENVIRONMENT FOR SYSTEM-LEVEL DESIGN

ECL: A SPECIFICATION ENVIRONMENT FOR SYSTEM-LEVEL DESIGN / ECL: A SPECIFICATION ENVIRONMENT FOR SYSTEM-LEVEL DESIGN Gerard Berry Ed Harcourt Luciano Lavagno Ellen Sentovich Abstract We propose a new specification environment for system-level design called ECL.

More information

Dealing with Issues for Interprocess Communication

Dealing with Issues for Interprocess Communication Dealing with Issues for Interprocess Communication Ref Section 2.3 Tanenbaum 7.1 Overview Processes frequently need to communicate with other processes. In a shell pipe the o/p of one process is passed

More information

Deadlock. Before We Begin. What is Deadlock? Traffic Jam as Example of Deadlock. CSE 120: Principles of Operating Systems. Lecture 6.

Deadlock. Before We Begin. What is Deadlock? Traffic Jam as Example of Deadlock. CSE 120: Principles of Operating Systems. Lecture 6. SE 120: Principles of Operating Systems Lecture 6 eadlock January 30, 2006 Prof. Joe Pasquale epartment of omputer Science and Engineering University of alifornia, San iego efore We egin Read hapter 7

More information

fakultät für informatik informatik 12 technische universität dortmund Specifications Peter Marwedel TU Dortmund, Informatik /11/15

fakultät für informatik informatik 12 technische universität dortmund Specifications Peter Marwedel TU Dortmund, Informatik /11/15 12 Specifications Peter Marwedel TU Dortmund, Informatik 12 2008/11/15 Graphics: Alexandra Nolte, Gesine Marwedel, 2003 Structure of this course Application Knowledge 3: Embedded System HW 2: Specifications

More information

Fall 2015 COMP Operating Systems. Lab 06

Fall 2015 COMP Operating Systems. Lab 06 Fall 2015 COMP 3511 Operating Systems Lab 06 Outline Monitor Deadlocks Logical vs. Physical Address Space Segmentation Example of segmentation scheme Paging Example of paging scheme Paging-Segmentation

More information

Programming Languages for Real-Time Systems. LS 12, TU Dortmund

Programming Languages for Real-Time Systems. LS 12, TU Dortmund Programming Languages for Real-Time Systems Prof. Dr. Jian-Jia Chen LS 12, TU Dortmund 20 June 2016 Prof. Dr. Jian-Jia Chen (LS 12, TU Dortmund) 1 / 41 References Slides are based on Prof. Wang Yi, Prof.

More information

An Esterel Virtual Machine for Embedded Systems

An Esterel Virtual Machine for Embedded Systems SLA 6 An Esterel Virtual Machine for Embedded Systems Becky lummer Department of Computer Science Columbia University New York, USA Mukul Khajanchi Department of Computer Science Columbia University New

More information

Real-Time and Concurrent Programming Lecture 4 (F4): Monitors: synchronized, wait and notify

Real-Time and Concurrent Programming Lecture 4 (F4): Monitors: synchronized, wait and notify http://cs.lth.se/eda040 Real-Time and Concurrent Programming Lecture 4 (F4): Monitors: synchronized, wait and notify Klas Nilsson 2016-09-20 http://cs.lth.se/eda040 F4: Monitors: synchronized, wait and

More information

The Verilog Language COMS W Prof. Stephen A. Edwards Fall 2002 Columbia University Department of Computer Science

The Verilog Language COMS W Prof. Stephen A. Edwards Fall 2002 Columbia University Department of Computer Science The Verilog Language COMS W4995-02 Prof. Stephen A. Edwards Fall 2002 Columbia University Department of Computer Science The Verilog Language Originally a modeling language for a very efficient event-driven

More information

INSTITUT FÜR INFORMATIK

INSTITUT FÜR INFORMATIK INSTITUT FÜR INFORMATIK A Sequentially Constructive Circuit Semantics for Esterel Alexander Schulz-Rosengarten, Steven Smyth, Reinhard von Hanxleden, Michael Mendler Bericht Nr. 1801 February 2018 ISSN

More information

Using Weakly Ordered C++ Atomics Correctly. Hans-J. Boehm

Using Weakly Ordered C++ Atomics Correctly. Hans-J. Boehm Using Weakly Ordered C++ Atomics Correctly Hans-J. Boehm 1 Why atomics? Programs usually ensure that memory locations cannot be accessed by one thread while being written by another. No data races. Typically

More information

Synchronization SPL/2010 SPL/20 1

Synchronization SPL/2010 SPL/20 1 Synchronization 1 Overview synchronization mechanisms in modern RTEs concurrency issues places where synchronization is needed structural ways (design patterns) for exclusive access 2 Overview synchronization

More information

Overview. Synchronous Languages Lecture 12. Code Generation for Sequential Constructiveness. Compilation Overview. The 5-Minute Review Session

Overview. Synchronous Languages Lecture 12. Code Generation for Sequential Constructiveness. Compilation Overview. The 5-Minute Review Session Synchronous Languages Lecture 12 Overview Prof. Dr. Reinhard von Hanxleden Steven Smyth Christian-Albrechts Universität Kiel Department of Computer Science Real-Time Systems and Embedded Systems Group

More information

The Java Memory Model

The Java Memory Model Jeremy Manson 1, William Pugh 1, and Sarita Adve 2 1 University of Maryland 2 University of Illinois at Urbana-Champaign Presented by John Fisher-Ogden November 22, 2005 Outline Introduction Sequential

More information

Concurrent Models of Computation

Concurrent Models of Computation Concurrent Models of Computation Edward A. Lee Robert S. Pepper Distinguished Professor, UC Berkeley EECS 219D Concurrent Models of Computation Fall 2011 Copyright 2009-2011, Edward A. Lee, All rights

More information

Operating Systems. Designed and Presented by Dr. Ayman Elshenawy Elsefy

Operating Systems. Designed and Presented by Dr. Ayman Elshenawy Elsefy Operating Systems Designed and Presented by Dr. Ayman Elshenawy Elsefy Dept. of Systems & Computer Eng.. AL-AZHAR University Website : eaymanelshenawy.wordpress.com Email : eaymanelshenawy@yahoo.com Reference

More information

IT 540 Operating Systems ECE519 Advanced Operating Systems

IT 540 Operating Systems ECE519 Advanced Operating Systems IT 540 Operating Systems ECE519 Advanced Operating Systems Prof. Dr. Hasan Hüseyin BALIK (5 th Week) (Advanced) Operating Systems 5. Concurrency: Mutual Exclusion and Synchronization 5. Outline Principles

More information

A Deterministic Concurrent Language for Embedded Systems

A Deterministic Concurrent Language for Embedded Systems SHIM:A A Deterministic Concurrent Language for Embedded Systems p. 1/28 A Deterministic Concurrent Language for Embedded Systems Stephen A. Edwards Columbia University Joint work with Olivier Tardieu SHIM:A

More information

Synthesizable Verilog

Synthesizable Verilog Synthesizable Verilog Courtesy of Dr. Edwards@Columbia, and Dr. Franzon@NCSU http://csce.uark.edu +1 (479) 575-6043 yrpeng@uark.edu Design Methodology Structure and Function (Behavior) of a Design HDL

More information

CSE Traditional Operating Systems deal with typical system software designed to be:

CSE Traditional Operating Systems deal with typical system software designed to be: CSE 6431 Traditional Operating Systems deal with typical system software designed to be: general purpose running on single processor machines Advanced Operating Systems are designed for either a special

More information

SystemC 1.3. Languages for Embedded Systems. Prof. Stephen A. Edwards Summer 2004 NCTU, Taiwan

SystemC 1.3. Languages for Embedded Systems. Prof. Stephen A. Edwards Summer 2004 NCTU, Taiwan SystemC 1.3 Languages for Embedded Systems Prof. Stephen A. Edwards Summer 2004 NCTU, Taiwan Designing Big Digital Systems Even Verilog or VHDL s behavioral modeling is not high-level enough People generally

More information

Compiling Esterel. Dumitru Potop-Butucaru. Stephen A. Edwards Gérard Berry

Compiling Esterel. Dumitru Potop-Butucaru. Stephen A. Edwards Gérard Berry Compiling Esterel Compiling Esterel Dumitru Potop-Butucaru Stephen A. Edwards Gérard Berry A C.I.P. Catalogue record for this book is available from the Library of Congress. ISBN 978-0-387-70626-9 (HB)

More information

SPIN, PETERSON AND BAKERY LOCKS

SPIN, PETERSON AND BAKERY LOCKS Concurrent Programs reasoning about their execution proving correctness start by considering execution sequences CS4021/4521 2018 jones@scss.tcd.ie School of Computer Science and Statistics, Trinity College

More information

Analyzing Real-Time Systems

Analyzing Real-Time Systems Analyzing Real-Time Systems Reference: Burns and Wellings, Real-Time Systems and Programming Languages 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich Real-Time Systems Definition Any system

More information

Real-Time Programming Languages (ADA and Esterel as Examples)

Real-Time Programming Languages (ADA and Esterel as Examples) Real-Time Programming Languages (ADA and Esterel as Examples) Real-Time Systems, 2008 RT Languages, 1 RT Language Classes HLL suitable for RT-Analysis (e.g., rms or time-driven) Synchronous HLL (clock

More information

Dataflow Languages. Languages for Embedded Systems. Prof. Stephen A. Edwards. March Columbia University

Dataflow Languages. Languages for Embedded Systems. Prof. Stephen A. Edwards. March Columbia University Dataflow Languages Languages for Embedded Systems Prof. Stephen A. Edwards Columbia University March 2009 Philosophy of Dataflow Languages Drastically different way of looking at computation Von Neumann

More information

Resource Sharing & Management

Resource Sharing & Management Resource Sharing & Management P.C.P Bhatt P.C.P Bhatt OS/M6/V1/2004 1 Introduction Some of the resources connected to a computer system (image processing resource) may be expensive. These resources may

More information

Process Management And Synchronization

Process Management And Synchronization Process Management And Synchronization In a single processor multiprogramming system the processor switches between the various jobs until to finish the execution of all jobs. These jobs will share the

More information

The SPIN Model Checker

The SPIN Model Checker The SPIN Model Checker Metodi di Verifica del Software Andrea Corradini Lezione 1 2013 Slides liberamente adattate da Logic Model Checking, per gentile concessione di Gerard J. Holzmann http://spinroot.com/spin/doc/course/

More information

Ch 9: Control flow. Sequencers. Jumps. Jumps

Ch 9: Control flow. Sequencers. Jumps. Jumps Ch 9: Control flow Sequencers We will study a number of alternatives traditional sequencers: sequential conditional iterative jumps, low-level sequencers to transfer control escapes, sequencers to transfer

More information

CMSC 714 Lecture 14 Lamport Clocks and Eraser

CMSC 714 Lecture 14 Lamport Clocks and Eraser Notes CMSC 714 Lecture 14 Lamport Clocks and Eraser Midterm exam on April 16 sample exam questions posted Research project questions? Alan Sussman (with thanks to Chris Ackermann) 2 Lamport Clocks Distributed

More information

Deadlock. Concurrency: Deadlock and Starvation. Reusable Resources

Deadlock. Concurrency: Deadlock and Starvation. Reusable Resources Concurrency: Deadlock and Starvation Chapter 6 Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate with each other No efficient solution Involve conflicting

More information

ELEC 377 Operating Systems. Week 1 Class 2

ELEC 377 Operating Systems. Week 1 Class 2 Operating Systems Week 1 Class 2 Labs vs. Assignments The only work to turn in are the labs. In some of the handouts I refer to the labs as assignments. There are no assignments separate from the labs.

More information

Chapter 5 Concurrency: Mutual Exclusion and Synchronization

Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles Chapter 5 Concurrency: Mutual Exclusion and Synchronization Seventh Edition By William Stallings Designing correct routines for controlling concurrent

More information

Lecture 3: Concurrency & Tasking

Lecture 3: Concurrency & Tasking Lecture 3: Concurrency & Tasking 1 Real time systems interact asynchronously with external entities and must cope with multiple threads of control and react to events - the executing programs need to share

More information

Synchronous Statecharts. Christian Motika

Synchronous Statecharts. Christian Motika Execution (KlePto) Esterel to transformation (KIES) Synchronous Statecharts for executing Esterel with Ptolemy Christian Motika Real-Time Systems and Embedded Systems Group Department of Computer Science

More information

CSc33200: Operating Systems, CS-CCNY, Fall 2003 Jinzhong Niu December 10, Review

CSc33200: Operating Systems, CS-CCNY, Fall 2003 Jinzhong Niu December 10, Review CSc33200: Operating Systems, CS-CCNY, Fall 2003 Jinzhong Niu December 10, 2003 Review 1 Overview 1.1 The definition, objectives and evolution of operating system An operating system exploits and manages

More information

Control Flow. COMS W1007 Introduction to Computer Science. Christopher Conway 3 June 2003

Control Flow. COMS W1007 Introduction to Computer Science. Christopher Conway 3 June 2003 Control Flow COMS W1007 Introduction to Computer Science Christopher Conway 3 June 2003 Overflow from Last Time: Why Types? Assembly code is typeless. You can take any 32 bits in memory, say this is an

More information

Important Lessons. A Distributed Algorithm (2) Today's Lecture - Replication

Important Lessons. A Distributed Algorithm (2) Today's Lecture - Replication Important Lessons Lamport & vector clocks both give a logical timestamps Total ordering vs. causal ordering Other issues in coordinating node activities Exclusive access to resources/data Choosing a single

More information

Threads. Concurrency. What it is. Lecture Notes Week 2. Figure 1: Multi-Threading. Figure 2: Multi-Threading

Threads. Concurrency. What it is. Lecture Notes Week 2. Figure 1: Multi-Threading. Figure 2: Multi-Threading Threads Figure 1: Multi-Threading Figure 2: Multi-Threading Concurrency What it is 1. Two or more threads of control access a shared resource. Scheduler operation must be taken into account fetch-decode-execute-check

More information

Cover Page. The handle holds various files of this Leiden University dissertation

Cover Page. The handle   holds various files of this Leiden University dissertation Cover Page The handle http://hdl.handle.net/1887/22891 holds various files of this Leiden University dissertation Author: Gouw, Stijn de Title: Combining monitoring with run-time assertion checking Issue

More information

Module 6: Process Synchronization. Operating System Concepts with Java 8 th Edition

Module 6: Process Synchronization. Operating System Concepts with Java 8 th Edition Module 6: Process Synchronization 6.1 Silberschatz, Galvin and Gagne 2009 Module 6: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores

More information

Safe Reactive Programming: the FunLoft Proposal

Safe Reactive Programming: the FunLoft Proposal Safe Reactive Programming: the FunLoft Proposal Frédéric Boussinot MIMOSA Project, Inria Sophia-Antipolis (Joint work with Frédéric Dabrowski) http://www.inria.fr/mimosa/rp With support from ALIDECS SYNCHRON

More information

Multiprocessors & Thread Level Parallelism

Multiprocessors & Thread Level Parallelism Multiprocessors & Thread Level Parallelism COE 403 Computer Architecture Prof. Muhamed Mudawar Computer Engineering Department King Fahd University of Petroleum and Minerals Presentation Outline Introduction

More information

RACE CONDITIONS AND SYNCHRONIZATION

RACE CONDITIONS AND SYNCHRONIZATION RACE CONDITIONS AND SYNCHRONIZATION Lecture 21 CS2110 Fall 2010 Reminder 2 A race condition arises if two threads try and share some data One updates it and the other reads it, or both update the data

More information

Concurrent Programming

Concurrent Programming Concurrency Concurrent Programming A sequential program has a single thread of control. Its execution is called a process. A concurrent program has multiple threads of control. They may be executed as

More information

Homework # 7 Distributed Computing due Saturday, December 13th, 2:00 PM

Homework # 7 Distributed Computing due Saturday, December 13th, 2:00 PM Homework # 7 Distributed Computing due Saturday, December 13th, 2:00 PM In this homework you will add code to permit a calendar to be served to clients, and to open a calendar on a remote server. You will

More information

Midterm Exam Solutions Amy Murphy 28 February 2001

Midterm Exam Solutions Amy Murphy 28 February 2001 University of Rochester Midterm Exam Solutions Amy Murphy 8 February 00 Computer Systems (CSC/56) Read before beginning: Please write clearly. Illegible answers cannot be graded. Be sure to identify all

More information

Safety SPL/2010 SPL/20 1

Safety SPL/2010 SPL/20 1 Safety 1 system designing for concurrent execution environments system: collection of objects and their interactions system properties: Safety - nothing bad ever happens Liveness - anything ever happens

More information

Real-Time Programming

Real-Time Programming Real-Time Programming Week 7: Real-Time Operating Systems Instructors Tony Montiel & Ken Arnold rtp@hte.com 4/1/2003 Co Montiel 1 Objectives o Introduction to RTOS o Event Driven Systems o Synchronization

More information

Need for synchronization: If threads comprise parts of our software systems, then they must communicate.

Need for synchronization: If threads comprise parts of our software systems, then they must communicate. Thread communication and synchronization There are two main aspects to Outline for Lecture 19 multithreaded programming in Java: I. Thread synchronization. thread lifecycle, and thread synchronization.

More information

10/17/ Gribble, Lazowska, Levy, Zahorjan 2. 10/17/ Gribble, Lazowska, Levy, Zahorjan 4

10/17/ Gribble, Lazowska, Levy, Zahorjan 2. 10/17/ Gribble, Lazowska, Levy, Zahorjan 4 Temporal relations CSE 451: Operating Systems Autumn 2010 Module 7 Synchronization Instructions executed by a single thread are totally ordered A < B < C < Absent synchronization, instructions executed

More information

Concurrency COMS W4115. Prof. Stephen A. Edwards Spring 2002 Columbia University Department of Computer Science

Concurrency COMS W4115. Prof. Stephen A. Edwards Spring 2002 Columbia University Department of Computer Science Concurrency COMS W4115 Prof. Stephen A. Edwards Spring 2002 Columbia University Department of Computer Science Concurrency Multiple, simultaneous execution contexts. Want to walk and chew gum at the same

More information

Chapter 5 Asynchronous Concurrent Execution

Chapter 5 Asynchronous Concurrent Execution Chapter 5 Asynchronous Concurrent Execution Outline 5.1 Introduction 5.2 Mutual Exclusion 5.2.1 Java Multithreading Case Study 5.2.2 Critical Sections 5.2.3 Mutual Exclusion Primitives 5.3 Implementing

More information

Implementing Coroutines. Faking Coroutines in Java

Implementing Coroutines. Faking Coroutines in Java Concurrency Coroutines Concurrency COMS W4115 Prof. Stephen A. Edwards Spring 2002 Columbia University Department of Computer Science Multiple, simultaneous execution contexts. Want to walk and chew gum

More information

Administrivia. CSE 370 Spring 2006 Introduction to Digital Design Lecture 9: Multilevel Logic

Administrivia. CSE 370 Spring 2006 Introduction to Digital Design Lecture 9: Multilevel Logic SE 370 Spring 2006 Introduction to igital esign Lecture 9: Multilevel Logic Last Lecture Introduction to Verilog Today Multilevel Logic Hazards dministrivia Hand in Homework #3 Homework #3 posted this

More information

Microkernel/OS and Real-Time Scheduling

Microkernel/OS and Real-Time Scheduling Chapter 12 Microkernel/OS and Real-Time Scheduling Hongwei Zhang http://www.cs.wayne.edu/~hzhang/ Ack.: this lecture is prepared in part based on slides of Lee, Sangiovanni-Vincentelli, Seshia. Outline

More information

Page 1. Challenges" Concurrency" CS162 Operating Systems and Systems Programming Lecture 4. Synchronization, Atomic operations, Locks"

Page 1. Challenges Concurrency CS162 Operating Systems and Systems Programming Lecture 4. Synchronization, Atomic operations, Locks CS162 Operating Systems and Systems Programming Lecture 4 Synchronization, Atomic operations, Locks" January 30, 2012 Anthony D Joseph and Ion Stoica http://insteecsberkeleyedu/~cs162 Space Shuttle Example"

More information

Operating Systems. Lecture 4 - Concurrency and Synchronization. Master of Computer Science PUF - Hồ Chí Minh 2016/2017

Operating Systems. Lecture 4 - Concurrency and Synchronization. Master of Computer Science PUF - Hồ Chí Minh 2016/2017 Operating Systems Lecture 4 - Concurrency and Synchronization Adrien Krähenbühl Master of Computer Science PUF - Hồ Chí Minh 2016/2017 Mutual exclusion Hardware solutions Semaphores IPC: Message passing

More information

Chapter 6: Synchronization. Chapter 6: Synchronization. 6.1 Background. Part Three - Process Coordination. Consumer. Producer. 6.

Chapter 6: Synchronization. Chapter 6: Synchronization. 6.1 Background. Part Three - Process Coordination. Consumer. Producer. 6. Part Three - Process Coordination Chapter 6: Synchronization 6.1 Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure

More information

Introduction. Coherency vs Consistency. Lec-11. Multi-Threading Concepts: Coherency, Consistency, and Synchronization

Introduction. Coherency vs Consistency. Lec-11. Multi-Threading Concepts: Coherency, Consistency, and Synchronization Lec-11 Multi-Threading Concepts: Coherency, Consistency, and Synchronization Coherency vs Consistency Memory coherency and consistency are major concerns in the design of shared-memory systems. Consistency

More information

Shared Memory Programming. Parallel Programming Overview

Shared Memory Programming. Parallel Programming Overview Shared Memory Programming Arvind Krishnamurthy Fall 2004 Parallel Programming Overview Basic parallel programming problems: 1. Creating parallelism & managing parallelism Scheduling to guarantee parallelism

More information

Chapter 6: Process Synchronization

Chapter 6: Process Synchronization Chapter 6: Process Synchronization Chapter 6: Synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Mutex Locks 6.6 Semaphores 6.7 Classic

More information

High Performance Computing Course Notes Shared Memory Parallel Programming

High Performance Computing Course Notes Shared Memory Parallel Programming High Performance Computing Course Notes 2009-2010 2010 Shared Memory Parallel Programming Techniques Multiprocessing User space multithreading Operating system-supported (or kernel) multithreading Distributed

More information

CSL373: Lecture 5 Deadlocks (no process runnable) + Scheduling (> 1 process runnable)

CSL373: Lecture 5 Deadlocks (no process runnable) + Scheduling (> 1 process runnable) CSL373: Lecture 5 Deadlocks (no process runnable) + Scheduling (> 1 process runnable) Past & Present Have looked at two constraints: Mutual exclusion constraint between two events is a requirement that

More information

CPS 110 Midterm. Spring 2011

CPS 110 Midterm. Spring 2011 CPS 110 Midterm Spring 2011 Ola! Greetings from Puerto Rico, where the air is warm and salty and the mojitos are cold and sweet. Please answer all questions for a total of 200 points. Keep it clear and

More information

CS370 Operating Systems

CS370 Operating Systems CS370 Operating Systems Colorado State University Yashwant K Malaiya Fall 2017 Lecture 11 Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ Multilevel Feedback Queue: Q0, Q1,

More information

CS 571 Operating Systems. Midterm Review. Angelos Stavrou, George Mason University

CS 571 Operating Systems. Midterm Review. Angelos Stavrou, George Mason University CS 571 Operating Systems Midterm Review Angelos Stavrou, George Mason University Class Midterm: Grading 2 Grading Midterm: 25% Theory Part 60% (1h 30m) Programming Part 40% (1h) Theory Part (Closed Books):

More information

Operating Systems: William Stallings. Starvation. Patricia Roy Manatee Community College, Venice, FL 2008, Prentice Hall

Operating Systems: William Stallings. Starvation. Patricia Roy Manatee Community College, Venice, FL 2008, Prentice Hall Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 6 Concurrency: Deadlock and Starvation Patricia Roy Manatee Community College, Venice, FL 2008, Prentice Hall Deadlock

More information

CSE 153 Design of Operating Systems

CSE 153 Design of Operating Systems CSE 153 Design of Operating Systems Winter 19 Lecture 7/8: Synchronization (1) Administrivia How is Lab going? Be prepared with questions for this weeks Lab My impression from TAs is that you are on track

More information

Virtual Machine Design

Virtual Machine Design Virtual Machine Design Lecture 4: Multithreading and Synchronization Antero Taivalsaari September 2003 Session #2026: J2MEPlatform, Connected Limited Device Configuration (CLDC) Lecture Goals Give an overview

More information

Deadlock. Lecture 4: Synchronization & Communication - Part 2. Necessary conditions. Deadlock handling. Hierarchical resource allocation

Deadlock. Lecture 4: Synchronization & Communication - Part 2. Necessary conditions. Deadlock handling. Hierarchical resource allocation Lecture 4: Synchronization & ommunication - Part 2 [RTS h 4] Deadlock Priority Inversion & Inheritance Mailbox ommunication ommunication with Objects Deadlock Improper allocation of common resources may

More information

Interprocess Communication By: Kaushik Vaghani

Interprocess Communication By: Kaushik Vaghani Interprocess Communication By: Kaushik Vaghani Background Race Condition: A situation where several processes access and manipulate the same data concurrently and the outcome of execution depends on the

More information

Synchronization Principles

Synchronization Principles Synchronization Principles Gordon College Stephen Brinton The Problem with Concurrency Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms

More information

AST: scalable synchronization Supervisors guide 2002

AST: scalable synchronization Supervisors guide 2002 AST: scalable synchronization Supervisors guide 00 tim.harris@cl.cam.ac.uk These are some notes about the topics that I intended the questions to draw on. Do let me know if you find the questions unclear

More information

High-level Synthesis from the Synchronous Language Esterel

High-level Synthesis from the Synchronous Language Esterel High-level Synthesis from the Synchronous Language Esterel Stephen. Edwards epartment of omputer Science olumbia University, New York bstract Producing efficient circuits from high-level language descriptions

More information

Mapping and architecture exploration

Mapping and architecture exploration Mapping and architecture exploration onfigure the resources, e.g. the size of an internal memory, width of a bus. Map the processes to the resources. ompile the processes in terms of the services provided

More information

Operating Systems. Synchronization

Operating Systems. Synchronization Operating Systems Fall 2014 Synchronization Myungjin Lee myungjin.lee@ed.ac.uk 1 Temporal relations Instructions executed by a single thread are totally ordered A < B < C < Absent synchronization, instructions

More information

Potential violations of Serializability: Example 1

Potential violations of Serializability: Example 1 CSCE 6610:Advanced Computer Architecture Review New Amdahl s law A possible idea for a term project Explore my idea about changing frequency based on serial fraction to maintain fixed energy or keep same

More information