Concurrency. Lecture 14: Concurrency & exceptions. Why concurrent subprograms? Processes and threads. Design Issues for Concurrency.

Similar documents
Chapter Machine instruction level 2. High-level language statement level 3. Unit level 4. Program level

Chapter 13 Topics. Introduction. Introduction

Chapter 13. Concurrency ISBN

CPS 506 Comparative Programming Languages. Programming Language Paradigms

14. Exception Handling

Exception Handling: Control. Exception handling is the control of error conditions or other unusual events during the execution of a program.

Exception handling. Exceptions can be created by the hardware or by software: Examples. Printer out of paper End of page Divide by 0

Performance Throughput Utilization of system resources

Chapter 14. Exception Handling and Event Handling 异常处理和事件处理. 孟小亮 Xiaoliang MENG, 答疑 ISBN

Chapter 14. Exception Handling and Event Handling

Programming Languages Third Edition. Chapter 9 Control I Expressions and Statements

Concurrent Programming. CS105 Programming Languages Supplement

Chapter 14. Exception Handling and Event Handling ISBN

CSE 130 Programming Language Principles & Paradigms Lecture # 20. Chapter 13 Concurrency. + AJAX Discussion

Concurrency - Topics. Introduction Introduction to Subprogram-Level Concurrency Semaphores Monitors Message Passing Java Threads

Ch 9: Control flow. Sequencers. Jumps. Jumps

Dealing with Issues for Interprocess Communication

Resource management. Real-Time Systems. Resource management. Resource management

Chapter 5 Concurrency: Mutual Exclusion and Synchronization

Chapter 5 Concurrency: Mutual Exclusion. and. Synchronization. Operating Systems: Internals. and. Design Principles

Real-Time Systems. Lecture #4. Professor Jan Jonsson. Department of Computer Science and Engineering Chalmers University of Technology

IT 540 Operating Systems ECE519 Advanced Operating Systems

Chapter 7 Control I Expressions and Statements

Process Management And Synchronization

Concurrent Processes Rab Nawaz Jadoon

Threading and Synchronization. Fahd Albinali

Process Synchronization

Chapter 6: Synchronization. Operating System Concepts 8 th Edition,

Process Synchronization: Semaphores. CSSE 332 Operating Systems Rose-Hulman Institute of Technology

Chapter 5 Asynchronous Concurrent Execution

Synchronization Principles

INSTITUTE OF AERONAUTICAL ENGINEERING

Informatica 3. Marcello Restelli. Laurea in Ingegneria Informatica Politecnico di Milano 9/15/07 10/29/07

G52CON: Concepts of Concurrency Lecture 15: Message Passing. Gabriela Ochoa School of Computer Science & IT

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

Lecture 9: Control Flow

Interprocess Communication By: Kaushik Vaghani

Semaphore. Originally called P() and V() wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; }

Synchronization: Semaphores

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

Chapter 6: Process Synchronization

CSE 153 Design of Operating Systems Fall 2018

SYNCHRONIZATION M O D E R N O P E R A T I N G S Y S T E M S R E A D 2. 3 E X C E P T A N D S P R I N G 2018

Non-blocking Array-based Algorithms for Stacks and Queues. Niloufar Shafiei

CHAPTER 6: PROCESS SYNCHRONIZATION

CSE 153 Design of Operating Systems

Parallel And Distributed Compilers

Processes. Rafael Ramirez Dep Tecnologia Universitat Pompeu Fabra

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

G52CON: Concepts of Concurrency

Structuring the Computation. Structuring the Computation

CSE 451: Operating Systems Winter Lecture 7 Synchronization. Steve Gribble. Synchronization. Threads cooperate in multithreaded programs

10/17/2011. Cooperating Processes. Synchronization 1. Example: Producer Consumer (3) Example

CS370 Operating Systems

C340 Concurrency: Semaphores and Monitors. Goals

Dr. D. M. Akbar Hussain DE5 Department of Electronic Systems

St. MARTIN S ENGINEERING COLLEGE Dhulapally, Secunderabad

CSE332: Data Abstractions Lecture 22: Shared-Memory Concurrency and Mutual Exclusion. Tyler Robison Summer 2010

CS 153 Design of Operating Systems Winter 2016

Defensive Programming

Synchronization I. Jo, Heeseung

Last Class: Synchronization

G52CON: Concepts of Concurrency

G Programming Languages Spring 2010 Lecture 13. Robert Grimm, New York University

IV. Process Synchronisation

Process Synchronisation (contd.) Operating Systems. Autumn CS4023

CSE 451: Operating Systems Winter Lecture 7 Synchronization. Hank Levy 412 Sieg Hall

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

ENGR 3950U / CSCI 3020U UOIT, Fall 2012 Quiz on Process Synchronization SOLUTIONS

Models of concurrency & synchronization algorithms

Chapter 6: Process Synchronization

*uuumuuuuuum// EIIIIIEEIIIE- ll~~llllll IIIIIIIIIENI. ll~~lllllllii

Concurrency: Mutual Exclusion and Synchronization. Concurrency

Concurrent Programming

Concurrency Control. Synchronization. Brief Preview of Scheduling. Motivating Example. Motivating Example (Cont d) Interleaved Schedules

Overview. Lab advice. Lab advice. Readers-writers problem. Readers-writers solution. Real-time Systems D0003E 3/10/2009

Lecture 9: Parameter Passing, Generics and Polymorphism, Exceptions

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

Multitasking / Multithreading system Supports multiple tasks

Copyright 2008 CS655 System Modeling and Analysis. Korea Advanced Institute of Science and Technology

2. The system of... generally ran one job at a time. These were called single stream batch processing.

Chapter 7: Process Synchronization!

CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2002

Background. Module 6: Process Synchronization. Bounded-Buffer (Cont.) Bounded-Buffer. Background

Synchronization I. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University

Programming Languages

Java Threads. COMP 585 Noteset #2 1

Synchronization. Silvina Hanono Wachman Computer Science & Artificial Intelligence Lab M.I.T.

Concurrent Programming

General Objectives: To understand the process management in operating system. Specific Objectives: At the end of the unit you should be able to:

Concurrency: a crash course

COP4020 Programming Languages. Exception Handling Prof. Robert van Engelen

G52CON: Concepts of Concurrency

What's wrong with Semaphores?

1 Process Coordination

The S-Expression Design Language (SEDL) James C. Corbett. September 1, Introduction. 2 Origins of SEDL 2. 3 The Language SEDL 2.

R13 SET Discuss how producer-consumer problem and Dining philosopher s problem are solved using concurrency in ADA.

Process Synchronization

Summary Semaphores. Passing the Baton any await statement. Synchronisation code not linked to the data

Synchronization. Race Condition. The Critical-Section Problem Solution. The Synchronization Problem. Typical Process P i. Peterson s Solution

Transcription:

Lecture 14: Concurrency & exceptions Concurrency Processes and threads Semaphores, monitors and message passing Exception handling Concurrency Is is often desirable or necessary to execute parts of programs concurrently (in parallel). We can have physical concurrency two or more processors are used logical concurrency Conceptual concurrency which physically may be sequential (interleaving) Levels of concurrency Instruction level concurrent execution of machine instructions Statement level concurrent execution of statements. SIMD/MIMD Subprogram level concurrent execution of subprograms Program level concurrent execution of programs 1 2 Why concurrent subprograms? Processes and threads Many domains lend themselves naturally to concurrency. Nature / real life is parallel (aircraft control etc. ) Efficient use of multiprocessor architectures Needed in many interactive systems User / user and system / user Suitable language concepts is needed. The execution of a parallel program consists of several threads of control. A process (task) is a unit that can provide one thread of control, and be executed concurrently with other units. Synchronization is needed to work with common data Synchronization guarantees that S in thread T is executed correctly before or after S in thread T competition synchronization occurs if a resource (e.g a printer) can t be shared (mutual exclusion); order isn t important cooperation synchronization occurs when tasks have common goals; order is important (ex: producer-consumer) 3 4 Processes Design Issues for Concurrency A scheduler distributes processes on processors Heavyweight or lightweight processes Possible states: New Ready Running Blocked Dead Possible problems Deadlock Starvation (=> Fair scheduling) Non-determinism Speed dependent (real time) Providing competition and cooperation synchronization Semaphores Monitors Message passing Controlling task scheduling How and when tasks start and end execution How and when are tasks created 5 6 1

Semaphores A semaphore (Dijkstra 1965) is a data structure with two uninterruptible operations wait and release. Often they surround the code that is subject to synchronization. A semaphore has a counter (capacity) 0 and a queue (initially empty) for blocked processes If a process P executes wait(s) and the capacity of s is > 0 it is decreased by 1 otherwise P is placed in the semaphore s queue If a process P executes release(s) and the queue of s is empty its capacity is increased by 1 Otherwise the first process in the task-ready queue is activated (and is removed from the queue) Semaphores The semaphore operations must be indivisible! Initial value =1 => mutual exclusion (binary semaphore) If more than one semaphore ; order is crucial! Wrong order may lead to deadlock The programmer is responsible for the correct use of the semaphore. (Compiler cannor check) Easy to make errors! Errors in comp.synch => e.g. deadlock Errors in coop.synch => e.g buffer overflow Examples: Sebesta or Systemnära prog. 7 8 Monitors Message Passing A monitor encapsulates data structures and the operations which give access to them. (ADT!) Only one process at a time is given access to the monitor. A datatype queue is defined to facilitate cooperating synchronization. Its operations delay and continue can only be executed in a monitor. When delay(q) is executed the process is blocked, put in queue q. Other processes are can access the monitor. When continue(q) is executed the process releases the monitor, and the first process in q is activated. Monitor op:s, e.g. insert / remove uses delay/continue Message passing is a general model for concurrency It can model both semaphores and monitors It is not just for competition synchronization Central idea: task communication is like seeing a doctor--most of the time she waits for you or you wait for her, but when you are both ready, you get together, or rendezvous Synchronous (above) or asynchronous 9 10 Message Passing Rendezvous Ada synchronization by message passing To support concurrent tasks with message passing, a language needs: - A mechanism to allow a task to indicate when it is willing to accept messages - A way to remember who is waiting to have its message accepted and some fair way of choosing the next message When a sender task s message is accepted by a receiver task, the actual message transmission is called a rendezvous In Ada processes can send and receive synchronization messages. If both sender and receiver are ready a rendezvous occurs, otherwise one of them have to wait. A task declares (in the task specification) entry points where it can accepts messages from other tasks. entry xyz (<parameters>) accept xyz(<parameters>) <body> (in the task body) means wait until a process P sends the message xyz, then execute <body> while P is blocked" 11 12 2

Rendezvous Time Lines Cooperation synchronization by message passing Tasks can have more than one entry point Non-deterministic choice using the select-structure: select when <villkor> => accept abc( ) or when <villkor> => accept xyz( ) end select An accept clause with a guard is either open if the guard is true closed if the guard is false a clause without a guard is always open 13 14 Semantics of Tasks with Multiple accept Clauses If exactly one entry queue is nonempty, choose a message from it If more than one entry queue is nonempty, choose one, nondeterministically, from which to accept a message If all are empty, wait The construct is often called a selective wait Extended accept clause - code following the clause, but before the next clause Executed concurrently with the caller Competition synchr. implicit, only one accept clause can be active at a time 15 Semantics of select with Guarded accept Clauses: select first checks the guards on all clauses If exactly one is open, its queue is checked for messages If more than one are open, non-deterministically choose a queue among them to check for messages If all are closed, it is a runtime error A select clause can include an else clause to avoid the error When the else clause completes, the loop repeats Example: Sebesta section 13.6.3 16 Concurrency in Ada 95 Ada 95 includes Ada 83 features for concurrency, plus two new features Protected objects: A more efficient way of implementing shared data to allow access to a shared data structure to be done without rendezvous. (Similar to monitors) Asynchronous communication Evaluation Semaphores are primitive but flexible, error prone. Different units cooperate on a low and detailed level. Monitors are similar to ADT:s and have similar advantages, but cooperation synchronization remains complicated. Message passing is simpler and more flexible than monitors, but still powerful, general and well-structured. Fits well with distributed systems. 2009-12-11 1-17 f. 18 3

Java s Thread Evaluation Java s support for concurrency is relatively simple but effective Not as powerful as Ada s tasks Concurrency in C# An advance over Java threads, e.g., any method can run its own thread Thread termination is cleaner than in Java Synchronization is more sophisticated Statement-level concurrency High Performance Fortran A collection of extensions that allow the programmer to provide information to the compiler to help it optimize code for multiprocessor architectures Specify the number of processors, the distribution of data over the memories of these processors, and the alignment of data Usually several processors which executes the same code, SIMD 2009-12-11 1-19 f. 20 Statement-level concurrency Functional languages, no inherent sequentiality, different types of concurrency possible. No side effects, only data dependencies controls execution order. (Sub)expressions can be evaluated in any order, even in parallel (Church-Rosser!) No new language concepts / constructions necessary (in principle), implicit parallelism Exception handling - Basic Concepts Many languages allow programs to trap input/output errors (including EOF) An exception is any unusual event, either erroneous or not, detectable by either hardware or software, that may require special processing The special processing that may be required after detection of an exception is called exception handling The exception handling code unit is called an exception handler An exception is raised when its associated event occurs 21 22 Exception handling Exception handling (cont) A program which cannot handle unusual events, exceptions isnʼt robust. We want to be able to Specify actions to be taken when an exception is detected Separate this from the main algorithm in the program Advantages Error detection code is tedious to write and clutters the program Exception handling encourages programmers to consider many different errors Exception propagation allows a high level of reuse of exception handling code Design issues: How do you define / declare an exception? Can exceptions have parameters? How is an exception activated (raised)? How do we define the units which should handle a raised exception? How is a raised exception bound to an exception handler? What is the scope of an exception handler? How (far) are exceptions propagated? Where is control transfered when a handler has finished? 23 24 4

An example: exceptions in Ada Ada, example Predefined + user defined exceptions Handlers can be bound to a block / subprogram / package / task Exceptions cannot have parameters When an exception is raised the unit is terminated, control is transfered to the handler. If there is no handler the exception is propagated to the calling unit. State-of-the-art in the 1980:s, but not without problems procedure P is BAD_FORMAT: exception; procedure Q is if S/= then raise BAD_FORMAT; end if end Q procedure R is Q; exception when BAD_FORMAT=>handler body 1 end R R; Q; exception when BAD_FORMAT=>handler body 2 end P; 25 26 Exception Handling in Java Summary Based on that of C++, but more in line with OOP philosophy All exceptions are objects of classes that are descendants of the Throwable class Read by yourself (if you re not already familiar with it) The Ada design for exception handling embodies the state-of-the-art in language design in the 80:s Ada was the only widely used language with exception handling until it was added to C++ Java and ML are other languages with well developed exception handling 2009-12-11 1-27 f. 28 5