Exceptions and Concurrency

1

• Exceptions and Concurrency

2
Error Handling

• Run-time errors happen
• File I/O errors
• Out of memory
• Bugs
• How can we handle them
• Without obscuring the normal flow of control
• Without duplicating a lot of code
• At an appropriate place
• Without causing more errors
• Error handling code can be very error prone since
• The state of the system cannot be depended on
• It is difficult to test exhaustively

3
Exceptions

• General mechanism for handling abnormal
  conditions
• Predefined exceptions constraint violations, I/O
  errors, communication errors, other illegalities
• User-defined exceptions for robust abstractions
• Predefined exception raised by the runtime
  system. User-defined exception can be raised
  (thrown) by user code.
• Exception handlers specify remedial actions or
  proper shutdown
• Exceptions can be stored and re-raised later

4
Predefined exceptions in Ada

• Defined in Standard
• Constraint_Error value out of range
• Program_Error illegality not detectable at
  compile-time unelaborated package, exception
  during finalization...
• Storage_Error allocation cannot be satisfied
  (heap or stack)
• Tasking _Error communication failure
• Defined in Ada.IO_Exceptions
• Data_Error, End_Error, Name_Error, Use_Error,
  Mode_Error, Status_Error, Device_Error

5
Handling exceptions

• Any begin-end block can have an exception
  handler
• procedure test is
• x integer 25
• y integer 0
• begin
• x x / y
• exception
• when Constraint_Error gt Put_Line
  (as expected)
• when others gt
  Put_Line (out of the blue!)
• end

6
A common idiom

• with Integer_Text_Io use Integer_Text_Io
• function Get_Data return Integer is
• X Integer
• begin
• loop
  -- as long as input is not legal
• begin
• Get (X)
• return X --
  if here, input is valid
• exception
• when others gt Put_Line
  (input must be integer, try again)
• end
• end loop
• end

7
Exception propagation

• When an exception is raised, control is passed
  directly to the nearest handler for that
  exception
• The current sequence of statements is abandoned
• All functions on the stack called after the one
  containing the handler for the exception are
  discarded.
• If no handler is found, the program terminates
• The current frame is never resumed

8
Unwinding the Stack

• If the exception is raised in a block for which
  an exception handler is present
• The handler is executed
• Control resumes at the next statement following
  the begin-end block
• Otherwise,
• the current stack frame is discarded
• The caller is found by following a dynamic chain.
• The exception is raised at the point of the call
  in the callers stack frame
• The process repeats until a handler is found.

9
User-defined Exceptions

• Client-server contract if inputs are proper,
  either the output is correct or else client is
  notified of failure. The inputs are the
  responsibility of the client (the caller).
• package Stacks is
• Stack_Empty exception
• package body Stacks is
• procedure Pop (X out Integer
  From in out Stack) is
• begin
• if Empty (From) then raise
  Stack_Empty
• else
• ...

10
The scope of exceptions

• Exception has the same visibility as other
  declared entities to handle an exception it must
  be visible in the handler
• An others clause can handle unameable exceptions
  partially
• when others gt
• Put_Line (disaster somewhere)
• raise -- propagate
  exception,
• -- program will terminate if exception is
  never caught

11
Exception information

• An exception is not a type we cannot declare
  exception variables and assign to them
• An exception occurrence is a value that can be
  stored and examined
• An exception occurrence may include additional
  information source location of occurrence,
  contents of stack, etc.
• Predefined package Ada.Exceptions contains needed
  machinery.

12
Ada.Exceptions

• package Ada.Exceptions is
• type Exception_Id is private
• type Exception_Occurrence is limited
  private
• function Exception_Identity (X
  Exception_Occurrence)
• 
  return
  Exception_Id
• function Exception_Name (X
  Exception_Occurrence) return String
• procedure Save_Occurrence
• (Target out Exception_Occurrence
• Source Exception_Occurrence)
• procedure Raise_Exception (E Exception_Id
  Message in String )
• ...

13
Using exception information

• exception
• when Expected Constraint_Error gt
• Save_Occurrence (Event_Log,
  Expected)
• when Trouble others gt
• Put_Line (unexpected
  Exception_Name (Trouble) raised)
• Put_Line (shutting down)
• raise
• ...

14
Exceptions in C

• Same runtime model
• Exceptions are classes
• Handlers appear in try blocks
• try
• some_complex_calculation ()
• catch (range_error) // range
  error might be raised
• //
  in some_complex_calculation
• cerr ltlt oops\n
• catch (zero_divide) // ditto for
  zero_divide
• cerr ltlt why is x
  zero?\n

15
Defining and throwing exceptions

• The program throws an object. There is nothing in
  the declaration to indicate it will be used as an
  exception.
• struct Zero_Divide
• public
• int lineno
  // useful information
• Zero_Divide ()
  // constructor
• try
• if (x 0) throw Zero_Divide
  (..) // call constructor and go

16
Exceptions and inheritance

• A handler names a class, and can handle an object
  of a derived class as well
• class Matherr // a
  bare object, no info
• class Overflow public Matherr
  
• class Underflow public Matherr
  
• class Zero_Divide public Matherr
  
• try
• weather_prediction_model ()
  
• // who knows what will happen
• catch (Overflow) // e.g.
  change parameters in caller
• catch (Matherr) //
  Underflow, Zero_Divide handled her
• catch () //
  handle anything else (ellipsis)

17
Handling Exception Hierarchy

• In C Exceptions are handled in order
• try
• myFile.open()
• buffer myFile.read(128)
• catch (FileNotFoundException e)
• catch (EndOfFileException e)
• catch FileIOException e)
• catch IOException e)
• Uses the first matching type (including base
  types)
• So, more general exceptions must follow more
  specific ones

18
Exceptions in Java

• Model and terminology similar to C
• exceptions are objects that are thrown and caught
• try blocks have handlers, which are examined in
  succession
• a handler for an exception can handle any object
  of a derived class
• Differences
• all exceptions are extension of predefined class
  Throwable
• checked exceptions are part of method declaration
• the finally clause specifies clean-up actions
  that are always executed

19
If a method might throw an exception, callers
should know about it

• public void replace (String name, Object
  newvalue)
• 
  throws NoSuchName
• Attribute attr find (name)
• if (attr null)
• throw new NoSuchName (name)
• newvalue.update (attr)
• Caller must have a handler for NoSuchName , or
  else must be declared as throwing NoSuchName
  itself.
• Only required for checked exceptions (not
  predefined ones, which are extensions of
  RuntimeException and Error).

20
And Finally

• Some cleanups must be performed whether the
  method terminates normally or throws an
  exception.
• public void encrypt (String file) throws
  StreamException
• Stream input
• try
• input new Stream (file)
• iterator Words new iterator
  (input)
• for (word w Words.init ()
  Words.more() w Words.next())
• RSAencode(word)
  // may fail somewhere
• finally if (input ! null)
  input.close() //regardless of how we exit

21

• Tasks and Concurrency

22
Tasking

• Processes and Threads
• Concurrent Programming
• Declaration, creation, activation, termination
• Synchronization and communication
• Semaphores
• Monitors
• Conditional communication
• Language Support
• C relies on libraries
• ADA and Java include language support
• What about purely functional programs?

23
Processes v. Threads

• Each running program is a process that runs in a
  separate address space
• Process started by user or by another program
• Communication between processes controlled by the
  Operating System
• A Process may have many threads
• Threads are sometimes called lightweight
  processes
• Each thread within a process
• Shares the same address space (heap and static
  memory)
• Has its own stack and local environment
• Has its own program counter
• Executes independently of other threads
• Often executes the same code as other threads

24
Concurrent programming

• Synchronous and asynchronous models of
  communication
• Description of simultaneous, independent
  activities
• A task is an independent thread of control, with
  own stack, program counter and local environment
• Tasks communicate through
• Rendez-vous
• protected objects
• Shared variables

25
Task Declarations in Ada

• A task type is a limited type
• task type worker -- declaration
  public interface
• type Worker_Id is access worker --
  a conventional access type
• task body worker is -- actions
  performed in lifetime
• begin
• loop -- forever. Will be
  shutdown from the outside.
  compute
• end loop
• end worker

26
Task Declarations in Ada

• A task type can be a component of a composite.
• The number of tasks in a program is not fixed at
  compile-time.
• W1, W2 Worker
  -- two individual tasks
• type Crew is array (Integer range ltgt)
  of worker
• First_Shift Crew (1 .. 10)
  -- a group of tasks
• type Monitored is record
• Counter Integer
• Agent Worker
• end record

27
Task Activation in Ada

• When does a task start running?
• If statically allocated, at the next begin
• If dynamically allocated, at the point of
  allocation.
• declare
• W1, W2 Worker
• Joe Worker_Id new Worker
  -- Starts working at once
• Third_Shift Crew (1..N) --
  some number of them
• begin -- activate W1, W2, and the
  third_shift
• 
  
• end -- wait for them (not Joe) --
  to complete

28
Task Services in Ada

• A task can perform some actions on request from
  another task
• The interface (declaration) of the task specifies
  the available actions (entries)
• A task can also execute some actions on its own
  behalf, without external requests or
  communication.
• task type Device is
• entry Read (X out Integer)
• entry Write (X Integer)
• end Device

29
Tasks in Java

• Code to run in thread is in a class that
  implements the interface Runnable and its run
  method
• Start Thread by
• Creating a Thread object from the Runnable object
• Calling Thread.start
• class f implements Runnable
• void run()
• new Thread(f).start()
• The Thread class provides methods to name, group,
  suspend, or interrupt the thread.d

30
Synchronization in Java

• Synchronize keyword is applied to objects
• Synchronized methods apply to this object
• Synchronized static methods apply to Class
  object
• Introduces a monitor for code that reads and
  writes to common memory
• Does not prevent deadlocks

31
Shared Variables

• 1. void LinkListinsert(Element newElt, Element
  after)
• 2. newElt.next after.next
• 3. newElt.prev after
• 4. after.next.prev newElt
• 5. after.next newElt
• 6
• What if another thread gains control at line 4
  and inserts another element at the same place?
• Need to be able to lock an object so other
  threads cannot interfere.
• lock list
• list.insert(newElt, after)
• unlock list
• What if we need to lock two lists in two threads?
• // Thread A // Thread B
• lock list a lock list b
• lock list b lock list a
• If thread B interrupts thread A between lock
  statements Deadlock!

32
Spin Locks

• A spin lock is an operating system primitive
• One thread obtains a spin lock
• Other threads awaiting the lock spin, until the
  lock is released
• Raises IRQ and Dispatch level so that no other
  threads can run. (adequate for single processor)
• Threads running on other processors must use
  atomic instructions (e.g., test-and-set) to
  determine when lock is freed.
• Can stop all other processing while it is held
• Does not require overhead of a context switch

33
Semaphores

• Developed by Dijkstra in the 1960s
• Semaphore is a structure S containing
• A counter s initialized to some positive value
• A queue q of threads waiting to enter the guarded
  section of code.
• P(S) Guards entry to a section S of code
• P(S) s - 1 if (s lt 0) add task to queue q
  and block
• V(S)
• V(S) s 1 if (s lt 0) activate a task in
  queue, q
• If s is negative, s is the number of queued
  tasks
• If s is positive, s is the number of simultaneous
  threads allowed in critical section (usually 1)
• The definitions of P and V are considered atomic
  operations

34
Mutex and Critical Region

• Mutex (Mutual-Exclusion)
• Ensures that only one thread is executing in a
  critical region
• Critical Region
• A region of code protected by mutual exclusion
• EnterCriticalRegion()
• doSomething()
• ExitCriticalRegion
• Programmer has to make sure no execution
  (including exceptions) path fails to close the
  mutex

35
Monitors

• Protects a section of code so that only one
  thread can execute the code at a time
• Defines a syntactic unit, avoids problem of
  having to explicitly end a critical region
• Uses semaphores to block additional threads
• Used by Java Synchronization

36
Synchronization Rendezvous

• Caller makes explicit request entry call
• Callee (server) states its availability accept
  statement
• If server is not available, caller blocks and
  queues up on the entry for later service
• If both present and ready, parameters are
  transmitted to server.
• Server performs action
• Out parameters are transmitted to caller
• Caller and server continue execution
  independently
• 
  

37
Example

• Simple mechanism to create critical sections
  section of code that must be executed by only one
  task at a time
• task type semaphore is
• entry P --
  Dijkstras terminology
• entry V -- from
  the Dutch
• end semaphore
• task body semaphore is
• begin
• loop
• accept P -- wont accept
  another P until a caller asks for V
• accept V
• end loop
• end semaphore
• 
  

38
Using a semaphore

• A task that needs exclusive access to the
  critical section executes
• Sema.P
• -- critical section code
• Sema.V
• If in the meantime another task calls Sema.P, it
  blocks, because the semaphore does not accept a
  call to P until after the next call to V the
  other task is blocked until the current one
  releases by making an entry call to V.
• programming hazards
• someone else may call V race condition
• no one calls V other callers are deadlocked.
  
  

39
Conditional Communication

• Need to protect against excessive delays,
  deadlock, starvation, caused by missing or
  malfunctioning tasks.
• Timed entry call caller waits for rendezvous a
  stated amount of time
• select
• Disk.Write (value gt 12, Track gt
  123) -- Disk is a task
• or
• delay 0.2
• end select
• If Disk does not accept within 0.2 Secs, go do
  something else.

40
Conditional Communication (ii)

• Conditional entry call caller ready for
  rendezvous only if no one else is queued, and
  rendezvous can begin at once
• select
• Disk.Write (value gt 12, Track gt
  123)
• else
• Put_Line (device busy)
• end select
• Print message if call cannot be accepted
  immediately.

41
Conditional communication (iii)

• The server may accept a call only if the internal
  state of the task is appropriate
• select
• when not full gt accept Write
  (Val Integer)
• or
• when not empty gt accept Read
  (Var out Integer)
• or
• delay 0.2 -- maybe
  something will happen
• end select
• If several guards are open and callers are
  present, any one of the calls may be accepted
  non-determinism.

42
Ada Protected Objects

• Protected types contain data that tasks can
  access only through a set of protected
  operations. Similar to Java Synchronized objects.
  
• Protected functions
• Read-only access to the internal data.
• Multiple tasks may simultaneously call a
  protected function.
• Protected procedures
• Exclusive read-write access to the internal data.
  
• Only one task at a time can interact with the
  protected type.
• Protected entries
• Like protected procedures except that they add a
  barrier condition.
• A barrier is a Boolean expression that must
  become true before the caller may proceed.
• If the barrier is not true when the caller makes
  a request, the caller is placed in a queue to
  wait until the barrier becomes true.