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

Transcription

1 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

2 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"

3 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 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 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 f. 18 3

4 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 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 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?

5 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; 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 f. 28 5