(12.1)COEN 171 - Concurrency and Exceptions

Coroutines Physical and logical concurrency Synchronization

– semaphores– monitors– message passing

Ada tasking Java threads Producer/consumer examples Exception handling

(12.2)Coroutines

Relax restriction on subprograms of single entry point– but only one is executing at any time

Provided by Simula 67, Modula-2, BLISS, INTERLISP Really like a subroutine with

– multiple entry points» which is valid controlled by coroutine

– means of maintaining state between activations» static local variables

Invoke coroutine with resume statement– often using variable to specify which coroutine to

resume Master Unit creates family of coroutines

– initialization segment executes for each as created– master resumes one coroutine, which invokes others– control returns to master when last coroutine ends

(12.3)Coroutines (continued)

Master

A B

Resume B

Resume A

Resume A

Resume B

Resume A

Classic example of coroutine structures

(12.4)

Coroutines (continued)

Master

A B

Resume B

Resume A

Resume A

Realistic example of coroutine structures

1st time

other times

Producer / Consumer

(12.5)Coroutines (continued)

Some languages allow coroutine creation dynamically, others only allow static creation

If dynamically created, memory allocation a problem– coroutines don’t follow stack discipline of

subprograms– string ARs for coroutines on linked list from AR of

master unit Coroutines can be

– full control statements in the language– provided as an add-on in a library

(12.6)Concurrency

Concurrency comes in several different flavors– Instruction level– Statement level– Unit level

» Primarily concentrate discussion here

– Program level Unit level concurrency relaxes restriction on

subprograms that invoking unit must suspend while invoked unit executes– also doesn’t satisfy stack discipline for subprogram

execution

(12.7)Concurrency (continued)

Unit of concurrency is the task– task is program unit with its own thread of control (path

through program statements)– task may be

» defined like subprogram» may have task type, and declaring variables of that type

creates a task instance

– task may be started » implicitly (by flowing into program unit where it was

declared)» explicitly

– tasks may be» New (just created)» Ready (or runnable)» Running» Blocked» Dead

– task is live if it continues to make progress towards completion

(12.8)Concurrency (continued)

Physical concurrency involves multiple hardware processors– simplest case 1 per task– issues of shared memory vs. local memory

Logical concurrency involves only a single hardware processor, but task execution interleaved so it seems like concurrent execution

Coroutines provide quasi concurrency Concurrency interesting since

– logical model of some problem domains » producer / consumer

– also issues of physical concurrency more common» parallel processing architectures

(12.9)Synchronization

Two or more tasks have no predefined order for execution yet often have to share “resources”– implies need for synchronization of tasks

If tasks know about each other, can use cooperation synchronization– tasks are written to voluntarily control correct

order of execution» Other process at stage I need? No, wait; yes, proceed

If no knowledge of other tasks, must use competition synchronization– to ensure mutually exclusive access to shared

resourcefetch A; A := X; store A

fetch A; A := Y; store A

(12.10)Implementing Synchronization

Binary semaphore– variable with initial value of 1– wait operation: if semaphore is 1, set to 0 and continue,

else queue– signal operation: if something in queue, remove first and

allow to continue, else semaphore := 1 Access to shared resource is

– wait(sema); use resource; signal (sema)– requires discipline and honorable intentions on part of all

programmers! General semaphore starts with initial value > 1, signal

increments semaphore by 1– implies more than one resource to share

Wait and signal are atomic operations (uninterruptible)– hardware instructions or in kernel

Any use of semaphores assumes error-free voluntary use of semaphore

(12.11)Synchronization (continued)

Monitors (Concurrent Pascal, Modula, Mesa) are way to synchronize without depending on programmers– think of as fence around

resource– access ports in fence

provide legal operations on resource» only 1 access point active

at any time» all calls made when some

port active are queued

Competition synchronization is guaranteed

Cooperation synchronization must still be provided by the programmer

Data

Structure

insert

remove

(12.12)Synchronization (continued)

Message passing is another way to synchronize– tasks send messages to each other to inform of

progress or request actions Phone model (synchronous)

– sender places call, waits until receiver picks it up» this connection called rendezvous

– in simplest form, sender continues after rendezvous

– in alternative form, sender waits for receiver to complete processing before continuing» whole “connect time” is rendezvous» similar to “remote procedure call”

(12.13)Ada 83 Tasking Model

Most advanced of any production language, but still controversial– message passing (phone) model

Tasks have two parts– specification indicates

» name of task» entry points (places where task will accept messages)

• include parameters if desired• not required unless intertask communication needed

» outside entity calls entry point, suspends until rendezvous

– body includes» one accept statement for each entry point

• accept <entry name> <parameters> do <clause body> end;• clause body is what gets executed during rendezvous

» body execution suspends when reach accept statement if no call from outside waiting for corresponding entry point

Become active at begin of declaring block

(12.14)Ada 83 Tasking Model (continued)

Can provide several accepts by placing in select statement (non-deterministically execute one)– can also attach guard to any accept– select– accept E1 do– end E1;– or– when SomeCondition => accept E2 do– end E2;– end select;– Guarded accept clauses implement cooperation synch.

Tasks may also be types and can even be dynamically created using new and assigning value to a pointer– task type Filter is entry E end Filter;– type filter_task is access filter; filter_2: filter_task;– filter_2 := new filter; filter_2.E;

(12.15)Ada 83 Tasking Model (continued)

Termination– If task hasn’t created dependent tasks, it

terminates when complete– If task has created dependent tasks, doesn’t

terminate until all dependents have terminated– Select statements can have terminate clauses

» Selected when no accept clauses are open

(12.16)Synchronization (continued again)

Mailbox model (asynchronous)– task 1 sends request to task 2, then proceeds– task 2 retrieves request when able and operates on

it– mailboxes can be

» 1 - 1 (sender specifies receiver, receiver specifies sender)

» many - 1 (sender specifies receiver, receiver takes any messages waiting regardless of source)

» many - many (no specification of particular receiver or sender)

– note model doesn’t require notification of completion of request» but “return receipt” sometimes included

– Not available in Ada 83, but exists in Ada 95

(12.17)Java Threads

Concurrent units in Java are run methods– Part of Thread class– Subclasses inherit and override run method from

Thread JVM provides a priority queue scheduler, typically

implemented as round-robin time slice Thread class includes several methods of relevance

to concurrency besides run– start, which calls run and control returns immediately

to caller» Means caller and run are executing simultaneously

– yield, which stops execution and puts thread in ready queue

– sleep, which suspends thread and blocks it for specified time

– resume, which restarts suspended thread– stop, which kills thread– setPriority and getPriority change or report thread’s

priority compared to other threads

(12.18)Java Threads (continued)

Competition synchronization– Synchronized modifier for methods

» Means method must be run to completion before any other methods for same object can run

» Other methods that want to run are queued, started when running method stops

– Synchronized statement allows synchronization on part of a method

» <expression> must evaluate to object, object is locked for duration of statement

Synchronized (<expression>)

statement

(12.19)Java Threads (continued)

Cooperation synchronization– All classes have wait and notify methods

» Part of root class, Object» Must be used inside synchronized method

– Wait is called inside a loop testing cooperation condition» Places thread in a queue if condition is not true

– Notify removes one waiting thread so it can proceed

try { while (! theCondition)

wait(); <do whatever needed after condition is true> }

catch (InterruptedException someProblem) { …}

(12.20)When to Choose Which Method

Need monitor or message passing for competition synchronization

On shared memory systems, message passing and monitors provide roughly similar performance

On local memory distributed systems, message passing is best

Can use message passing to implement other methodstask BINARY_SEMAPHORE IS

entry WAIT; entry SIGNAL;end BINARY_SEMAPHORE;task body BINARY_SEMAPHORE IS

begin loop

accept WAIT;accept SIGNAL;

end loop;end BINARY_SEMAPHORE;

(12.21)Exception Handling

Some languages provide special facilities for dealing with run-time errors and other special events– PL/I, CLU, Ada, Mesa, ML, C++, Java– events like divide by zero, running out of memory, etc.

Events are called exceptions, and facilities are called exception handlers– exceptions are said to be raised– these are more elaborate than simple I/O error handling

capabilities found in many primitive languages» BASIC, FORTRAN

Exceptions are synchronous events, unlike interrupts that are asynchronous events– exceptions occur at predictable points during execution

Languages with exception handling also usually provide mechanism for user-defined exceptions

(12.22)Exception Handling (continued)

Alternatives to exception handling include– Use the return value of a subprogram (or an

auxiliary status parameter) to indicate performance status (C)

– Pass a label parameter to all subprograms and return to label on error (FORTRAN)

– Pass an exception handling subprogram to all subprograms

Built-in exception handling has advantages– Error detection code is tedious to write and clutters

program, hindering readability– Exception propagation allows error handling code

to be reused

(12.23)Exception Design Issues

How are exception handlers specified, and what is scope?– usually specified with reserved word

» PL/I: on <ex. name> Ada: exception when <ex. name> =>

– modern trend is to have exception handlers appear at end of block

– scope is usually program unit in which defined How does the language determine which handler

to invoke when exception occurs– PL/I used dynamic

» most recently executed on statement for that exception

– other languages use static scope» specifying handler in program unit applies for entire

scope of unit

(12.24)Exception Design Issues (continued)

What if no handler in effect for unit where exception occurs?– usually propagate

» terminate unit» raise same exception in unit that called excepting

unit» continue until find handler or reach top level (when

program terminates!)» NOTE that this is a dynamic activity, even if exception

handler scope is static!!

– some languages allow defining a default exception handler» Ada: exception when others => handles any

exception not otherwise explicitly listed

(12.25)Exception Design Issues (continued)

Where does execution continue after exception handler finishes?– 1. terminate program unit that caused exception

and return to calling unit– 2. terminate program unit that caused exception

and raise same exception in calling unit» propagate one level even if handled

– 3. resume execution of program unit that raised exception, retrying statement when exception occurred

– 4. resume execution of program unit that raised exception with statement after one where exception occurred

Are there built-in exceptions, or only user-defined? Are there system provided default handlers? Can exceptions be disabled?

(12.26)PL/I

First widely used language with exception handling

Conditions could be built-in – 22 defined– Some always enabled, others enabled or disabled by

default but program could change Binding of handlers to exceptions is dynamic

– Define handler by ON <condition> begin; … end;» Effective within block where it appears

– ON is an executable statement Continuation could be

– Terminate program– Return control to statement where exception was

raised– User-defined exceptions could go to any labled

statement in program

(12.27)PL/I (continued)

User-defined exceptions created by declaring name– CONDITION foo– Can override built-in handlers

Exceptions raised by SIGNAL statement Exceptions enabled/disabled by program unit,

block, statement– (foo, NOSUBSCRIPTRANGE):

Evaluation– Dynamic binding of handlers makes programs

difficult to read and debug– Continuation rules confusing

(12.28)Ada

Exceptions are statically scoped– Apply to subprogram body, package body, task or

block Handlers always are placed at the end of the

block or unit to which they apply Propagation (if not handled locally) depends on

kind of unit– Procedures propagate to calling program unit– Blocks are “parameterless procedures” and

propagate to point after the block– Packages propagate to declaration section of unit

that declared package– Tasks don’t propagate, just terminate

Continuation– Any unit propagating exception is terminated– Since exceptions are always at the end of the unit,

if exception handled unit is also terminated

(12.29)Ada (continued)

Five built-in exceptions– Some may be disabled

Raise statement invokes exception General form is

begin

<code body>

exception

when name1 => <handler code>

when name2 => <handler code>

when others => <default handler code>

end;

(12.30)C++

Exception handling added to C++ in 1990– Only user-defined exceptions– Raised by throw <expression>– Can’t be disabled– Propagated dynamically to calling unit– If handled, continued at first statement after try construct

General form

Try {

<code body>

Catch (parameter) { … } linear search for handler

Catch (parameter) { … } if parameter … , default

(12.31)Java

Design much more consistent with OO philosophy– All exceptions descend from Throwable class

» Error subclass thrown by JVM, not handled by user» Exception subclass has two further predefined

subclasses (IOException and RuntimeException)– Uses try catch syntax

» Every parameter must be an object descended from Throwable

– Exception bound to first handler with a parameter of same class as thrown or an ancestor of that class

– Propagate to» Containing try construct» Method’s caller

– Methods must list all checked exceptions (those not descendents of Error and RuntimeException) they may throw, if not handled internally

– Finally clause allows cleanup, must be executed after any handler