concurrency and real-time programming support in java™, ada and posix

Concurrency andReal-Time

Programming Supportin Java™, Ada and POSIX

Ben Brosgol

Tutorial for SIGAda 2001October 1, 2001Bloomington, MN

79 Tobey RoadBelmont, MA 02478

USA

+1-617-489-4027 (Voice)+1-617-489-4009 (FAX)

[email protected]

-2-

Topics

Concurrency issues Basic model / lifetime Mutual exclusion Coordination / communication Asynchrony Interactions with exception handling

Real-time issues Memory management / predictability Scheduling and priorities (priority inversion

avoidance) Time / periodic activities

Java approach Java language specification Real-Time Specification for Java (Real-Time for Java

Expert Group) Core Extensions to Java (J-Consortium)

Ada 95 approach Core language Systems Programming and Real-Time Annexes

POSIX approach Pthreads (1003.1c) Real-time extensions (1003.1b)

For each issue, we present / compare the languages’ approaches

-3-

Concurrency Granularity / Terminology

“Platform” Hardware + OS + language-specific run-time library

“Process” Unit of concurrent execution on a platform

• Communicates with other processes on the same platform or on different platforms

Communication / scheduling managed by the OS (same platform) or CORBA etc (different platforms)

Concurrency on a platform may be true parallelism (multi-processor) or multiplexed (uniprocessor)

Per-process resources include stack, memory, environment, file handles, ...

Switching/communication between processes is expensive

“Thread” (“Task”) Unit of concurrent execution within a process

• Communicates with other threads of same process Shares per-process resources with other threads in the

same process Per-thread resources include PC, stack Concurrency may be true parallelism or multiplexed Communication / scheduling managed by the OS or by

language-specific run-time library Switching / communication between threads is cheap

Our focus: threads in a uniprocessor environment

-4-

Summary of Issues

Concurrency Basic model / generality Lifetime properties

• Creation, initialization, (self) termination, waiting for others to terminate

Mutual exclusion• Mechanism for locking a shared resource, including

control over blocking/awakening a task that needs the resource in a particular state

Coordination (synchronization) / communication Asynchrony

• Event / interrupt handling• Asynchronous Transfer of Control• Suspension / resumption / termination (of / by

others) Interactions with exception handling Libraries and thread safety

Real-Time Predictability (time, space) Scheduling policies / priority

• Range of priority values• Avoidance of “priority inversion”

Clock and time-related issues and services• Range/granularity, periodicity, timeout

Libraries and real-time programming

-5-

Overview of Java Concurrency Support (1)

Java Preliminaries Smalltalk-based, dynamic, safety-sensitive OO

language with built-in support for concurrency, exception handling

Dynamic data model• Aggregate data (arrays, class objects) on heap• Only primitive data and references on stack• Garbage Collection required

Two competing proposals for real-time extensions• Sun-sponsored Real-Time for Java Expert Group• J-Consortium

Basic concurrency model Unit of concurrency is the thread

• A thread is an instance of the class java.lang.Thread or one of its subclasses

• run() method = algorithm performed by each instance of the class

Programmer either extends Thread, or implements the Runnable interface• Override/implement run()

All threads are dynamically allocated• If implementing Runnable, construct a Thread

object passing a Runnable as parameter

-6-


Example of simple thread

Lifetime properties Constructing a thread creates the resources that

the thread needs (stack, etc.) “Activation” is explicit, by invoking start() Started thread runs “concurrently” with parent Thread terminates when its run method returns Parent does not need to wait for children to

terminate• Restrictions on “up-level references” from

inner classes prevent dangling references to parent stack data

public class Writer extends Thread{ final int count;

public Writer(int count){this.count=count;}

public void run(){ for (int i=1; i<=count; i++){ System.out.println("Hello " + i); } } public static void main( String[] args ) throws InterruptedException{ Writer w = new Writer(60); w.start(); // New thread of control invokes w.run() w.join(); // Wait for w to terminate } }

-7-


Mutual exclusion Shared data (volatile fields) synchronized blocks/methods

Thread coordination/communication Pass data to new thread via constructor Pulsed event - wait() / notify() Broadcast event - wait() / notifyAll() join() suspends caller until the target thread completes

Asynchrony interrupt() sets a bit that can be polled Asynchronous termination

• stop() is deprecated • destroy() is discouraged

suspend() / resume() have been deprecated RTJEG, J-C proposals include event / interrupt handling,

ATC, asynchronous termination

Interaction with exception handling No asynchronous exceptions in “baseline Java”

• Async exceptions for ATC in RTJEG, J-C Various thread-related exceptions Thread propagating an unhandled exception

• Terminates, but first calls uncaughtException

Other functionality Thread group, dæmon threads, thread local data

-8-

Overview of Ada Concurrency Support (1)

Ada 95 preliminaries Pascal-based ISO Standard reliable OO language with built-

in support for packages (modules), concurrency, exception handling, generic templates, ...

Traditional data model (“static” storage, stack(s), heap)• Aggregate data (arrays, records) go on the stack unless

dynamically allocated• Implementation not required to supply Garbage

Collection “Specialized Needs Annexes” support systems

programming, real-time, several other domains

Basic concurrency model Unit of concurrency (thread) is the task

• Task specification = interface to other tasks•Often simply just the task name

• Task body = implementation (algorithm)•Comprises declarations, statements

• Task type serves as a template for task objects performing the same algorithm

Tasks and task types are declarations and may appear in “global” packages or local scopes• Tasks follow normal block structure rules• Each task has own stack• Task body may refer (with care :-) to data in outer

scopes, may declare inner tasks Task objects may be declared or dynamically allocated

-9-


Example of declared task object

Lifetime properties Declared task starts (is activated) implicitly at the begin of parent unit

Allocated task starts at the point of allocation Task statements execute “concurrently” with

statements of parent Task completes when it reaches its end “Master” is suspended when it reaches its end, until

each of its dependent tasks terminates• Prevents dangling references to local data

No explicit mechanism (such as Java’s join()) to wait for another task to terminate

with Ada.Text_IO;procedure Example1 is Count : Integer := 60; task Writer; -- Specification

task body Writer is -- Body begin for I in 1..Count loop Ada.Text_IO.Put_Line( "Hello" & Integer'Image(I)); delay 1.0; -- Suspend for at least 1.0 second end loop; end Writer;begin -- Writer activated null; -- Main procedure suspended until Writer terminatesend Example1;

-10-


Example of task type / dynamic allocation

Mutual exclusion Shared data, pragma Volatile / Atomic Protected objects / types

• Data + “protected” operations that are executed with mutual exclusion

“Passive” task that sequentializes access to a data structure via explicit communication (rendezvous)

Explicit mutex-like mechanism (definable as protected object/type) that is locked and unlocked

with Ada.Text_IO;procedure Example2 is task type Writer(Count : Natural); -- Specification

type Writer_Ref is access Writer; Ref : Writer_Ref;

task body Writer is -- Body begin for I in 1..Count loop Ada.Text_IO.Put_Line( "Hello" & I'Img); delay 1.0; -- Suspend for at least 1.0 second end loop; end Writer;

begin Ref := new Writer(60); -- activates new Writer task object -- Main procedure suspended until Writer object terminatesend Example2;

-11-


Coordination / communication Pass data to task via discriminant or rendezvous Suspension_Object

• Binary semaphore with 1-element “queue” Rendezvous

• Explicit inter-task communication Implicit wait for dependent tasks

Asynchrony Event handling via dedicated task, interrupt handler Asynch interactions subject to “abort deferral”

• abort statement• Asynchronous transfer of control via timeout or

rendezvous request• Hold / Continue procedures (suspend / resume)

Interaction with exception handling No asynchronous exceptions Tasking_Error raised at language-defined points Task propagating an (unhandled) exception

terminates silently

Other functionality Per-task attributes Restrictions for high-integrity / efficiency-sensitive

applications• Ravenscar Profile

-12-

Overview of POSIX Concurrency Support (1)

Basic concurrency model A thread is identified by an instance of (opaque)

type pthread_t Threads may be allocated dynamically or

declared locally (on the stack) or statically Program creates / starts a thread by calling pthread_create, passing the addresses of the thread id, an “attributes” structure, the function that the thread will be executing, and the function’s arguments• Thread function takes and returns void*• Return value passed to “join”ing thread

Example Notation: POSIX call in upper-case is a macro

whose expansion includes querying the error return code#include <pthread.h>

#include <stdio.h>void *tfunc(void *arg){ // thread function int count = *( (int*)arg ); int j; for (j=1; j <= count; j++){ printf("Hello %d\n", j); } return NULL;}int main(int argc, char *argv[]){ // main thread pthread_t pthread; int pthread_arg = 60; PTHREAD_CREATE( &pthread, NULL, tfunc, (void*)&pthread_arg); PTHREAD_JOIN( pthread, NULL );}

-13-


Lifetime properties Thread starts executing its thread function as result of pthread_create, concurrent with creator

Termination• A thread terminates via a return statement or by

invoking pthread_exit• Both deliver a result to a “join”ing thread, and both

invoke cleanup handlers• A terminated thread may continue to hold system

resources until it is recycled Detachment and recycling

• A thread is detachable if• It has been the target of a pthread_join or a pthread_detach (either before or after it has terminated), or

• it was created with its detachstate attribute set• A terminated detachable thread is recycled,

releasing all system resources not released at termination

No hierarchical relationship among threads• Created thread has a pointer into its creator’s

memory danger of dangling reference Main thread is special in that when it returns it

terminates the process, killing all other threads• To avoid this mass transitive threadicide, main

thread can pthread_exit rather than return

-14-


Mutual exclusion Mutexes (pthread_mutex_t type) with lock / unlock

functions

Coordination / communication Condition variables (pthread_cond_t type) with pulsed

and broadcast events Semaphores Data passed to thread function at pthread_create,

result delivered to “joining” thread at return or pthread_exit

Asynchrony Thread cancellation with control over immediacy and

ability to do cleanup

Interaction with exception handling Complicated relationship with signals Consistent error-return conventions

• The result of each pthread function is an int error code (0 normal)

• If the function needs to return a result, it does so in an address (“&”) parameter

• No use of errno in Pthreads functions•Per-thread errno used when a thread calls a

function that sets errno

Other Thread-specific data area “pthread once” functions

-15-

Comparison: Basic Model / Lifetime

Points of difference Nature of unit of concurrency: class, task,

function Implicit (Ada, POSIX) versus explicit (Java)

activation How parameters are passed / how result

communicated

Methodology / reliability Ada and Java provide type checking, prevent

dangling references

Flexibility / generality All three provide roughly the same expressive

power POSIX allows a new thread to be given its

parameters explicitly on thread creation POSIX allows a thread to return a value to a

“join”ing thread Ada lacks an explicit mechanism for one task to

wait for another task to terminate• In particular, waiting for an allocated task to

terminate

Efficiency Ada requires run-time support to manage task

dependence hierarchy

-16-

Mutual Exclusion in Ada via Shared Data

Example: One task repeatedly updates an integer value Another task repeatedly displays it

Advantage Efficiency

Need pragma Atomic to ensure that Integer reads/writes are atomic Optimizer does not cache Global

Drawbacks Methodologically challenged Does not scale up (e.g. aggregate data, more than one

updating task)

with Ada.Text_IO;procedure Example3 is Global : Integer := 0; pragma Atomic( Global ); task Updater; task Reporter; task body Updater is begin loop Global := Global+1; delay 1.0; -- 1 second end loop; end Updater; task body Reporter is begin loop Ada.Text_IO.Put_Line( Global'Img ); delay 2.0; -- 2 seconds end loop; end Reporter;begin null;end Example3;

Note: the assignment statement is not

atomic

-17-

Mutual Exclusion in Java via Shared Data

Java version of previous example

Comments Same advantages and disadvantages as Ada

version Need volatile to prevent hostile optimizations

public class Example4{ static volatile int global = 0; public static void main(String[] args){ Updater u = new Updater(); Reporter r = new Reporter(); u.start(); r.start(); }}class Updater extends Thread{ public void run(){ while(true){ Example4.global++; ... sleep( 1000 ); ... // try block omitted } }}class Reporter extends Thread{ public void run(){ while(true){ System.out.println(Example4.global); } ... sleep( 2000 ); ... // try block omitted } }}

-18-

with Ada.Integer_Text_IO;procedure Example5 is type Position is record X, Y : Integer := 0; end record; protected Global is procedure Update; function Value return Position; private Data : Position; end Global; protected body Global is procedure Update is begin Data.X := Data.X+1; Data.Y := Data.Y+1; end Update; function Value return Position is begin return Data; end Value; end Global; task Updater; task Reporter; task body Updater is begin loop Global.Update; delay 1.0; -- 1 second end loop; end Updater; task body Reporter is P : Position; begin loop P := Global.Value; Ada.Integer_Text_IO.Put (P.X); Ada.Integer_Text_IO.Put (P.Y); delay 2.0; -- 2 seconds end loop; end Reporter;begin null;end Example5;

Mutual Exclusion in Ada via Protected Object

Executedwith

mutualexclusion

Interface

Implementation

-19-

Basic Properties of Ada Protected Objects

A protected object is a data object that is shared across multiple tasks but with mutually exclusive access via a (conceptual) “lock” The rules support “CREW” access (Concurrent Read,

Exclusive Write)

Form of a protected object declaration

Encapsulation is enforced Client code can only access the protected

components through protected operations

Protected operations illustrated in Example5 Procedure may “read” or “write” the components Function may “read” the components, not “write”

them

The protected body provides the implementation of the protected operations

Comments on Example5 Use of protected object ensures that only one of the

two tasks at a time can be executing a protected operation

Scales up if we add more accessing tasks Allows concurrent execution of reporter tasks

protected Object_Name is { protected_operation_specification ; }[ private { protected_component_declaration } ]end Object_Name;

Data may only bein the private part

-20-

Mutual Exclusion in Java viaSynchronized Blocks

class Updater extends Thread{ private final Position pu; Updater( Position p ){ pu=p; } public void run(){ while(true){ synchronized(pu){ pu.x++; pu.y++; } ... sleep( 1000 ); ... } }}

class Reporter extends Thread{ private final Position pr; Reporter( Position p ){ pr=p; } public void run(){ while(true){ synchronized(pr){ System.out.println(pr.x); System.out.println(pr.y); } ... sleep( 2000 ); ... } }}

class Position{ int x=0, y=0;}

public class Example6{ public static void main(String[] args){ Position global = new Position(); Updater u = new Updater( global ); Reporter r = new Reporter( global ); u.start(); r.start(); }}

global

u

r

pu

pr

x

y

Position

Updater

Reporter

-21-

Semantics of Synchronized Blocks

Each object has a lock

Suppose thread t executes synchronized(p){...}

In order to enter the {...} block, t must acquire the lock associated with the object referenced by p If the object is currently unlocked, t acquires the lock

and sets the lock count to 1, and then proceeds to execute the block

If t currently holds the lock on the object, t increments its lock count for the object by 1, and proceeds to execute the block

If another thread holds the lock on the object, t is “stalled”

Leaving a synchronized block (either normally or “abruptly”) t decrements its lock count on the object by 1 If the lock count is still positive, t proceeds in its

execution If the lock count is zero, the threads “locked out” of

the object become eligible to run, and t stays eligible to run• But this is not an official scheduling point

If each thread brackets its accesses inside a synchronized block on the object, mutually exclusive accesses to the object are ensured No need to specify volatile

-22-

Mutual Exclusion in Java viaSynchronized Methods

class Updater extends Thread{ private final Position pu; Updater( Position p ){ pu=p; } public void run(){ while(true){ pu.incr(); ... sleep( 1000 ); ... } }}

class Reporter extends Thread{ private final Position pr; Reporter( Position p ){ pr=p; } public void run(){ while(true){ int[] arr = pr.value(); System.out.println(arr[0]); System.out.println(arr[1]); ... sleep( 2000 ); ... } }}

class Position{ private int x=0, y=0; public synchronized void incr(){ x += 1; y += 1; } public synchronized int[] value(){ return new int[2]{x, y} } }

public class Example7{ public static void main(String[] args){ Position global = new Position(); Updater u = new Updater( global ); Reporter r = new Reporter( global ); u.start(); r.start(); }}

global

u

r

pu

pr

x

y

Position

Updater

Reporter

-23-

Comments on Synchronized Blocks / Methods

Effect of synchronized instance method is as though body of method was in a synchronized(this) block

Generally better to use synchronized methods versus synchronized blocks Centralizes mutual exclusion logic For efficiency, have a non-synchronized method with synchronized(this) sections of code

Synchronized accesses to static fields A synchronized block may synchronize on a class

object• The “class literal” Foo.class returns a reference to

the class object for class Foo• Typical style in a constructor that needs to access

static fields

A static method may be declared as synchronized

Constructors are not specified as synchronized Only one thread can be operating on a given object

through a constructor

Invoking obj.wait() releases lock on obj All other blocking methods (join(), sleep(), blocking

I/O) do not release the lock

class MyClass{ private static int count=0; MyClass(){ synchronized(MyClass.class){ count++; } ... }}

-24-

Mutual Exclusion in POSIX via Mutex

A mutex is an instance of type pthread_mutex_t

Initialization determines whether a pthread can successfully lock a mutex it has already locked PTHREAD_MUTEX_INITIALIZER (“fast mutex”)

• Attempt to relock will fail PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP

(“recursive mutex”)• Attempt to relock will succeed

Operations on a mutex pthread_mutex_lock(&mutex)

• Blocks caller if mutex locked• Deadlock condition indicated via error code

pthread_mutex_trylock(&mutex)

• Does not block caller pthread_mutex_unlock(&mutex)

• Release waiting pthread pthread_mutex_destroy(&mutex)

• Release mutex resources• Can reuse mutex if reinitialize

-25-

Monitors

In most cases where mutual exclusion is required there is also a synchronization* constraint A task performing an operation on the object needs to

wait until the object is in a state for which the operation makes sense

Example: bounded buffer with Put and Get• Consumer calling Get must block if buffer is empty• Producer calling Put must block if buffer is full

The monitor is a classical concurrency mechanism that captures mutual exclusion + state synchronization Encapsulation

• State data is hidden, only accessible through operations exported from the monitor

• Implementation must guarantee that at most one task is executing an operation on the monitor

Synchronization is via condition variables local to the monitor• Monitor operations invoke wait/signal on the condition

variables• A task calling wait is unconditionally blocked (in a

queue associated with that condition variable), releasing the monitor

• A task calling signal awakens one task waiting for that variable and otherwise has no effect

Proposed/researched by Dijkstra, Brinch-Hansen, Hoare in late 1960s and early 1970s

* “Synchronization” in the correct (versus Java) sense

-26-

Monitor Example: Bounded Buffer

monitor Buffer {Pascal-like syntax} export Put, Get, Size; const Max_Size = 10; var Data : array[1..Max_Size] of Whatever; Next_In, Next_Out : 1..Max_Size; Count : 0..Max_Size;

NonEmpty, NonFull : condition; procedure Put(Item : Whatever); begin if Count=Max_Size then Wait( NonFull ); Data[Next_In] := Item; Next_In := Next_In mod Max_Size + 1; Count := Count + 1; Signal( NonEmpty ); end {Put}; procedure Get(Item : var Whatever); begin if Count=0 then Wait( NonEmpty ); Item := Data[Next_Out]; Next_Out := Next_Out mod Max_Size + 1; Count := Count - 1; Signal( NonFull ); end {Get}; function Size : Integer; begin Size := Count; end {Size};begin Count := 0; Next_In := 1; Next_Out := 1;end {Buffer};

Next_Out

Next_In

Max_Size 1Data

Count: 4

Snapshot of data structures afterinserting 5 elements

and removing 1

-27-

Monitor CritiqueSemantic issues If several tasks waiting for a condition variable, which

one is unblocked by a signal?• Longest-waiting, highest priority, unspecified, ...

Which task (signaler or unblocked waiter) holds the monitor after a signal• Signaler?• Unblocked waiter?

•Then when does signaler regain the monitor Require signal either to implicitly return or to be the last

statement? Depending on semantics, may need while vs if in the

code that checks the wait condition

Advantages Encapsulation Efficient implementation Avoids some race conditions

Disadvantages Sacrifices potential concurrency

• Operations that don’t affect the monitor’s state (e.g. Size) still require mutual exclusion

Condition variables are low-level / error-prone• Programmer must ensure that monitor is in a

consistent state when wait/signal are called Nesting monitor calls can deadlock, even without using

condition variables

-28-

Monitors and Java

Every object is a monitor in some sense Each object obj has a mutual exclusion lock, and

certain code is executed under control of that lock• Blocks that are synchronized on obj• Instance methods on obj’s class that are declared as

synchronized• Static synchronized methods for obj if obj is a class

But encapsulation depends on programmer style Non-synchronized methods, and accesses to non-

private data from client code, are not subject to mutual exclusion

No special facility for condition variables Any object (generally the one being accessed by

synchronized code) can be used as a condition variable via wait() / notify()

But that means that there is only one condition directly associated with the object

To invoke wait() or notify() on an object, the calling thread needs to hold the lock on the object Otherwise throws a run-time exception The notifying thread does not release the lock Waiting threads thus generally need to do their wait in

a while statement versus a simple if No guarantee which waiting thread is awakened by a

notify

-29-

Bounded Buffer in Java

Notes Essential for each wait() condition to be in a while

loop and not simply an if statement Important to signal via notifyAll() versus simply notify()

• A producer and a consumer thread may be in the object’s wait set at the same time!

public class BoundedBuffer{ public static final int maxSize=10; private final Object[] data = new Object[maxSize]; private int nextIn=0, nextOut=0; private volatile int count=0;

public synchronized void put(Object item) throws InterruptedException{ while (count == max) { this.wait(); } data[nextIn] = item; nextIn = (nextIn + 1) % max; count++; this.notifyAll(); }

public synchronized Object get() throws InterruptedException{ while (count == 0) { this.wait(); } Object result = data[nextOut]; data[nextOut] = null; nextOut = (nextOut + 1) % max; count--; this.notifyAll(); return result; } public int size(){ // not synchronized return count;}

-30-

Monitors and Ada Protected ObjectsEncapsulation enforced in both Data components are inaccessible to clients

Mutual exclusion enforced in both All accesses are via protected operations, which are

executed with mutual exclusion (“CREW”)

Condition variables A protected entry is a protected operation guarded by a

boolean condition (“barrier”) which, if false, blocks the calling task

Barrier condition can safely reference the components of the protected object and also the “Count attribute”• E'Count = number of tasks queued on entry E• Value does not change while a protected operation is

in progress (avoids race condition) Barrier expressions are Ada analog of condition

variables, but higher level (wait and signal implicit) • Caller waits if the barrier is False (and releases the

lock on the object)• Barrier conditions for non-empty queues are

evaluated at the end of protected procedures and protected entries

• If any are True, queuing policy establishes which task is made ready

Protected operations (unlike monitor operations) are non-blocking Allows efficient implementation of “lock”

-31-

Bounded Buffer in Ada

package Bounded_Buffer_Pkg is Max_Length : constant := 10; type W_Array is array(1 .. Max_Length) of Whatever; protected Bounded_Buffer is entry Put( Item : in Whatever ); entry Get( Item : out Whatever ); function Size; private Next_In, Next_Out : Positive := 1; Count : Natural := 0; Data : W_Array; end Bounded_Buffer;end Bounded_Buffer_Pkg;

package body Bounded_Buffer_Pkg is protected body Bounded_Buffer is entry Put( Item : in Whatever ) when Count < Max_Length is begin Data(Next_In) := Item; Next_In := Next_In mod Max_Length + 1; Count := Count+1; end Put; entry Get( Item : out Whatever ) when Count > 0 is begin Item := Data(Next_Out); Next_Out := Next_Out mod Max_Length + 1; Count := Count-1; end Get;

function Size is begin return Count; end Size; end Bounded_Buffer;end Bounded_Buffer_Pkg;

Evaluatebarriers

-32-

Monitors and POSIX:Mutex + Condition Variables

POSIX supplies type pthread_cond_t for condition variables Always used in conjunction with a mutex

• Avoids race conditions such as a thread calling wait and missing a signal that is issued before the thread is enqueued

May be used to simulate a monitor, or simply as an inter-thread coordination mechanism

Initialized via PTHREAD_COND_INITIALIZER or via pthread_cond_init function

Operations Waiting operations

• pthread_cond_wait( &cond_vbl, &mutex )• pthread_cond_timedwait(&cond_vbl, &mutex, &timeout)

Signaling operations• pthread_cond_signal( &cond_vbl )

•Pulsed event•No guarantee which waiter is awakened

• pthread_cond_broadcast (&cond_vbl )

•Broadcast event•All waiters awakened

Initialization• pthread_cond_init( &cond_val )

Resource release• pthread_cond_destroy( &cond_vbl )

-33-

Bounded Buffer in POSIX (*)

(*) Based on example in Burns & Wellings, Real-Time Systems and Programming Languages, pp. 253-254

#include <pthread.h>#define MAX_LENGTH 10#define WHATEVER floattypedef struct{ pthread_mutex_t mutex; pthread_cond_t non_full; pthread_cond_t non_empty; int next_in, next_out, count; WHATEVER data[MAX_LENGTH];} bounded_buffer_t;

void put( WHATEVER item, bounded_buffer_t *b ){ PTHREAD_MUTEX_LOCK(&(b->mutex)); while (b->count == MAX_LENGTH){ PTHREAD_COND_WAIT(&(b->non_full), &(b->mutex)); } ... /* Put data in buffer, update count and next_in */ PTHREAD_COND_SIGNAL(&(b->non_empty)); PTHREAD_MUTEX_UNLOCK(&(b->mutex));}

void get( WHATEVER *item, bounded_buffer_t *b ){ PTHREAD_MUTEX_LOCK(&(b->mutex)); while (b->count == 0){ PTHREAD_COND_WAIT(&(b->non_empty), &(b->mutex)); } ... /* Get data from buffer, update count and next_out */ PTHREAD_COND_SIGNAL(&(b->non_full)); PTHREAD_MUTEX_UNLOCK(&(b->mutex));}

int size( bounded_buffer_t *b ){ int n; PTHREAD_MUTEX_LOCK(&(b->mutex)); n = b->count; PTHREAD_MUTEX_UNLOCK(&(b->mutex)); return n;}/* Initializer function also required

-34-

Comparison of Mutual Exclusion Approaches

Points of difference Expression of mutual exclusion in program

• Explicit code markers in POSIX (lock/unlock mutex)• Either explicit code marker (synchronized block) or

encapsulated (synchronized method) in Java• Encapsulated (protected object) in Ada

No explicit condition variables in Java (or Ada) Blocking prohibited in protected operations (Ada) Locks are implicitly recursive in Java and Ada,

programmer decides whether “fast” or recursive in POSIX

Methodology / reliability All provide necessary mutual exclusion Ada entry barrier is higher level than condition

variable Absence of condition variable from Java can lead to

clumsy or obscure style Main reliability issue is interaction between mutual

exclusion and asynchrony, described below

Flexibility / generality Ada: protected operations need to be non-blocking

Efficiency Ada provides potential for concurrent reads Ada does not require queue management, but barrier

(re)evaluation entails overhead

-35-

Coordination / Communication Mechanisms

Pulsed Event Waiter blocks unconditionally Signaler awakens exactly one waiter (if one or

more), otherwise event is discarded

Broadcast Event Waiter blocks unconditionally Signaler awakens all waiters (if one or more),

otherwise event is discarded

Persistent Event (Binary Semaphore) Signaler allows one and only one task to

proceed past a wait• Some task that already has, or the next task

that subsequently will, call wait

Counting semaphore A generalization of binary semaphore, where

the number of occurrences of signal are remembered

Simple 2-task synchronization Persistent event with a one-element queue

Direct inter-task synchronous communication Rendezvous, where the task that initiates the

communication waits until its partner is ready

-36-

Pulsed Event

Java Any object can serve as a pulsed event via wait()

/ notify() Calls on these methods must be in code

synchronized on the object• wait() releases the lock, notify() doesn’t

wait() can throw InterruptedException An overloaded version of wait() can time out, but

no direct way to know whether the return was normal or via timeout

Ada Protected object / type can model a pulsed event

Can time out on any entry via select statement Can’t awaken a blocked task other than via abort

POSIX Condition variable can serve as pulsed event

protected type Pulsed_Event is entry Wait; procedure Signal;private Signaled : Boolean := False;end Pulsed_Event;

protected body Pulsed_Event is entry Wait when Signaled is begin Signaled := False; end Wait;

procedure Signal is begin Signaled := Wait'Count>0; end Signal;end Pulsed_Event;

-37-

Broadcast Event

Java Any object can serve as a broadcast event via wait() / notifyAll()

Calls on these methods must be in code synchronized on the object

Ada Protected object / type can model a broadcast

event

Protected object can model more general forms, such as sending data with the signal, to be retrieved by each awakened task

Locking protocol / barrier evaluation rules prevent race conditions

POSIX Condition variable can serve as broadcast event

protected type Broadcast_Event is entry Wait; procedure Signal;private Signaled : Boolean := False;end Broadcast_Event;

protected body Broadcast_Event is entry Wait when Signaled is begin Signaled := Wait'Count>0; end Wait;

procedure Signal is begin Signaled := Wait'Count>0; end Signal;end Broadcast_Event;

-38-

Semaphores (Persistent Event)

Binary semaphore expressible in Java

J-Consortium spec includes binary and counting semaphores

Binary semaphore expressible in Ada

POSIX Includes (counting) semaphores, but intended for

inter-process rather than inter-thread coordination

public class BinarySemaphore { private boolean signaled = false;

public synchronized void await() throws InterruptedException{ while (!signaled) { this.wait(); } signaled=false; } public synchronized void signal(){ signaled=true; this.notify(); }}

protected type Binary_Semaphore is entry Wait; procedure Signal;private Signaled : Boolean := False;end Binary_Semaphore;

protected body Binary_Semaphore is entry Wait when Signaled is begin Signaled := False; end Wait; procedure Signal is begin Signaled := True; end Signal;end Binary_Semaphore;

-39-

Simple Two-Task Synchronization

Java, POSIX No built-in support

Ada Type Suspension_Object in package Ada.Synchronous_Task_Control

• Procedure Suspend_Until_True(SO) blocks caller until SO becomes true, and then atomically resets SO to false

• Procedure Set_True(SO) sets SO’s state to true• “Bounded error” if a task calls Suspend_Until_True(SO) while another task is waiting for SO

procedure Proc is task Setter; task Retriever; SO : Suspension_Object; Data : array (1..1000) of Float;

task body Setter is begin ... -- Initialize Data Set_True(SO); ... end Setter;

task body Retriever is begin Suspend_Until_True(SO); ... -- Use data end Setter;begin null;end Proc;

-40-

Direct Synchronous Inter-Task Communication (1)

Calling task (caller) Requests action from another task (the callee),

and blocks until callee is ready to perform the action

Called task (callee) Indicates readiness to accept a request from a

caller, and blocks until a request arrives

Rendezvous Performance of the requested action by callee,

on behalf of a caller Parameters may be passed in either or both

directions Both caller and callee are unblocked after

rendezvous completes

Java No direct support Can model via wait / notify, but complicated

POSIX Same comments as for Java

“T2, do action A” • Wait for T2 to start action A• (T2 does action A)• Wait for T2 to complete action A

“Accept request for action A [from T1]” • Wait for request for action A [from T1]• Do action A• Awaken caller

T1 T2

Rendezvous

-41-


Ada “Action” is referred to as a task’s entry

• Declared in the task’s specification• Caller makes entry call, similar syntactically to a

procedure call• Callee accepts entry call via an accept statement

Caller identifies callee but not vice versa• Many callers may call the same entry, requiring a

queue Often callee is a “server” that sequentializes access

to a shared resource• Sometimes protected object is not sufficient, e.g.

if action may block• In most cases the server can perform any of

several actions, and the syntax needs to reflect this flexibility

• Also in most cases the server is written as an infinite loop (not known in advance how many requests will be made) so termination is an issue

•Ada provides special syntax for a server to automatically terminate when no further communication with it is possible

Caller and/or callee may time out • Timeout canceled at start of rendezvous

-42-


Ada example

task Sequentialized_Output is entry Put_Line( Item : String ); entry Put( Item : String );end Sequentialized_Output;

task body Sequentialized_Output isbegin loop select accept Put_Line( Item : String ) do Ada.Text_IO.Put_Line( Item ); end Put_Line; or accept Put( Item : String ) do Ada.Text_IO.Put( Item ); end Put; or terminate; end select; end loop;end Sequentialized_Output;

task Outputter1;task body Outputter1 isbegin; ... Sequentialized_OutPut. Put("Hello"); ...end Outputter1;

task Outputter2;task body Outputter2 isbegin; ... Sequentialized_Output. Put("Bonjour"); ...end Outputter2;

-43-

Comparison of Coordination/Communication

MechanismsPoints of difference Different choice of “building blocks”

• Ada: Suspension_Object, protected object, rendezvous

• Java, POSIX: pulsed/broadcast events Java allows “interruption” of blocked thread by

throwing an exception, Ada and POSIX allow only cancellation

Methodology / reliability Ada’s high-level feature (rendezvous) supports

good practice Potential for undetected bug in Ada if a task calls

Suspend_Until_True on a Suspension_Object that already has a waiting task

Flexibility / generality Major difference among the languages is that

Ada is the only one to provide rendezvous as built-in communication mechanism

Efficiency No major differences in implementation

efficiency for mechanisms common to the three approaches

Ada’s Suspension_Object has potential for greater efficiency than semaphores

-44-

Asynchrony Mechanisms

Setting/Polling Setting a datum in a task/thread that is polled by

the affected task/thread

Asynchronous Event Handling Responding to asynchronous events generated

internally (by application threads) or externally (by interrupts)

Resumptive: “interrupted” thread continues at the point of interruption, after the handler completes

Combine with polling or ATC to affect the interrupted thread

Asynchronous Termination Aborting a task/thread Immediacy: are there regions in which a task /

thread defers requests for it to be aborted?

ATC Causing a task to branch based on an asynchronous

occurrence Immediacy: are there regions in which a task /

thread defers requests for it to have an ATC?

Suspend/resume Causing a thread to suspend its execution, and later

causing the thread to be resumed Immediacy: are there regions in which a task /

thread defers requests for it to be suspended?

-45-

Setting / Polling

Not exactly asynchronous (since the affected task/thread checks synchronously) But often useful and arguably better than

asynchronous techniques

Ada No built-in mechanism, but can simulate via

protected object or pragma Atomic variable global to setter and poller

Java t.interrupt() sets interruption status flag in the

target thread t Static Thread method boolean interrupted()

returns current thread’s interruption status flag and resets it

Boolean method t.isInterrupted() returns target thread’s interruption status flag

If t.interrupt() is invoked on a blocked thread t, t is awakened and an InterruptedException (a checked exception) is thrown

Each of the methods thr.join(), Thread.sleep(), and obj.wait() has a “throws InterruptedException” clause

POSIX No built-in mechanism

-46-

Asynchronous Event Handling

Ada No specific mechanism for asynch event handling Interrupt handlers can be modeled by specially

identified protected procedures, executed (at least conceptually) by the hardware

Other asynch event handlers modeled by tasks

Java (RTSJ) Classes AsyncEvent (“AE”), AsyncEventHandler

(“AEH”) model asynchronous events, and handlers for such events, respectively• Programmer overrides one of the AEH methods to

define the handler’s action Program can register one or more AEHs with any AE

(listener model) An AEH is a schedulable entity, like a thread (but

not necessarily a dedicated thread) When an AE is fired, all registered handlers are

scheduled based on their scheduling parameters• Program needs to manage any data queuing• Methods allow dealing with event bursts

Scales up to large number of events, handlers J-Consortium proposal has analogous mechanism

POSIX Messy interaction between signals (originally a

process-based mechanism) and threads

-47-

Asynchronous Termination (1)

Ada Abort statement sets the aborted task’s state to

abnormal, but this does not necessarily terminate the aborted task immediately

For safety, certain contexts are abort-deferred; e.g.• Accept statements• Protected operations

Real-Time Annex requires implementation to terminate an abnormal task as soon as it is outside an abort-deferred region

Java Language Spec No notion of abort-deferred region Invoke t.stop(Throwable exc) or t.stop()

• Halt t asynchronously, and throw exc or ThreadDeath object in t

• Then effect is as though propagating an unchecked exception

• Deprecated (data may be left in an inconsistent state if t stopped while in synchronized code)

Invoke t.destroy()• Halt t, with no cleanup and no release of locks• Not (yet :-) deprecated but can lead to deadlock

Invoke System.exit(int status) • Terminates the JVM• By convention, nonzero status

abnormal termination

-48-


Java Language Spec (cont’d.) Recommended style is to use interrupt()

Main issue is latency

RTSJ Synchronized code, and methods that do not

explicitly have a throws clause for AIE, are abort deferred

To abort a thread, invoke t.interrupt() and have t do its processing in an asynchronously interruptible method

class Boss extends Thread{ Thread slave; Boss(Thread slave){ this.slave=slave; } public void run(){ ... if (...){ slave.interrupt(); // abort slave } ... }}class PollingSlave extends Thread{ public void run(){ while (!Thread.interrupted()){ ... // main processing } ... // pre-shutdown actions }}

-49-


J-Consortium abort() method aborts a thread Synchronized code is not necessarily abort-deferred

• May need to terminate a deadlocked thread that is in synchronized code

Synchronized code in objects that implement the Atomic interface is abort deferred

POSIX A pthread can set its cancellation state (enabled or

disabled) and, if enabled, its cancellation type (asynchronous or deferred)• pthread_set_cancelstate(newstate, &oldstate)

• PTHREAD_CANCEL_DISABLE• PTHREAD_CANCEL_ENABLE

• pthread_set_canceltype(newtype, &oldtype)• PTHREAD_CANCEL_ASYNCHRONOUS

• PTHREAD_CANCEL_DEFERRED • Default setting: enabled, deferred cancellation

Deferred cancel at next cancellation point• Minimal set of cancellation points defined by

standard, others can be added by implementation pthread_cancel( &pthr ) sends cancellation request Cleanup handlers give the cancelled thread the

opportunity to consistentize data, unlock mutexes

-50-

Asynchronous Transfer of Control (“ATC”)

What is it A mechanism whereby a triggering thread

(possibly an async event handler) can cause a target thread to branch unconditionally, without any explicit action from the target thread

Controversial facility Triggering thread does not know what state

the target thread is in when the ATC is initiated

Target thread must be coded carefully in presence of ATC

Implementation cost / complexity Interaction with synchronized code

Why provide support? User community requirement Useful for certain idioms

• Time out of long computation when partial result is acceptable

• Abort an iteration of a loop• Terminate a thread

ATC may have shorter latency than polling

-51-

Asynchronous Transfer of Control (1)

Ada Allow controlled ATC, where the effect is restricted

to an explicit syntactic context Restrict the ATC triggering conditions

• Time out• Acceptance of an entry call

Defer effect of ATC until affected task is outside abort-deferred region

Java (RTSJ) ATC based on model of asynchronous exceptions,

thrown only at threads that have explicitly enabled them

ATC deferred in synchronized code and in methods that lack a “throws AIE” clause

Timeout is a specific kind of AIE

function Eval(Interval : Duration) return Float is X : Float := 0.0; pragma Atomic( X );begin select delay Interval; return X; then abort while ... loop ... X := ...; ... end loop; end select; return X;end Eval;

1

2

3a

3b

-52-

Asynchronous Transfer of Control (2)abstract class Func{ abstract double f(double x) throws AIE; volatile double current; // assumes atomic}

class MyFunc extends Func{ double f(double x) throws AIE { current = ...; while(...){ ... current = ...; } return current; }}

class SuccessiveApproximation{ static boolean finished; static double calc(Func func, double arg, long ms){ double result = 0.0; new Timed( new RelativeTime(ms, 0) ).doInterruptible( new Interruptible(){ public void run(AIE e) throws AIE{ result = func.f(arg); finished = true; } public void interruptAction(AIE e){ result = func.current; finished = false; } }); return result; } public static void main(String[] args){ MyFunc mf = new MyFunc(); double answer = calc(mf, 100.0, 1000); // run mf.f(100.0) for at most 1 second System.out.println(answer); System.out.println("calc completed? " + finished ); }}

-53-

Suspend / Resume

Ada Real-Time Annex defines a package Ada.Asynchronous_Task_Control with procedures Hold, Continue

Hold(T) conceptually sets T’s priority less than that of the idle task• Effect deferred during protected

operations, rendezvous Continue(T) restores T’s pre-held priority

Java t.suspend() suspends t, without releasing

locks t.resume() resumes t These methods have been deprecated

• If a thread t is suspended while holding a lock required by the thread responsible for resuming t, the threads will deadlock

• Arguably this programming bug should not have caused the methods to be deprecated

POSIX Not supported

-54-

Comparison of Asynchrony Mechanisms

Points of difference Ada attempts a minimalist approach, whereas the

real-time Java specs (and to some extent POSIX) provide more general models

Methodology / reliability Asynchronous operations are intrinsically

dangerous, the goal is to minimize / localize the code that needs to be sensitive to disruption

Regular Java’s interrupt mechanism, though requiring polling, is a reasonable approach

Java RTSJ has nice model for asynchronous event handling

POSIX cancellation semantics allows thread owning a mutex to cleanly deal with cancellation request

Ada ATC constrains the effect of an asynchronous request to a clearly identified syntactic region, and defines orderly cleanup

POSIX signal interactions are messy

Flexibility / generality Java RTSJ offers a general ATC model based on

asynchronous exceptions

Efficiency ATC may incur distributed overhead in Java RTSJ

(check on method returns)

-55-

Scheduling and Priorities: Introduction

Scheduler decides which ready task to run (“dispatching”), which task to unblock when a resource with a queue of waiters is available

Variety of dispatching policies, including: Priority-based fixed priority(*), FIFO within priority

• Run until blocked (non-preemptive)• Run until blocked or preempted• Run until blocked or preempted or timeslice

expires Priority-based non-fixed priority

• Priority aging• Earliest deadline first

Variety of queue service policies, such as: FIFO ignoring priorities FIFO within priorities Unspecified

Finer levels of detail also arise When thread is preempted, or when its priority is

modified, where in its ready queue is it placed?

Scheduling policies affect predictability and throughput, goals which are in conflict Real-time programs generally require

predictability at expense of throughput

(*) “Fixed priority” scheduler does not implicitly change a thread’s priorityexcept to avoid priority inversions; program can change a thread’s priority

-56-

Priority Inversion

What is a “priority inversion”? A higher-priority thread is blocked / stalled while a

lower-priority thread is running

It is sometimes necessary When the lower priority thread holds a lock that is

needed by the higher priority thread

Scheduling policy affects worst case blocking time A high priority thread may be blocked (stalled on a

lock) during execution of a lower-priority thread not holding the lock - “unbounded priority inversion”• Mars lander mission in 1999

Priority Inheritance and Highest Lockers (Priority Ceiling) considerably reduce worst-case blocking time, at expense of throughput

Priority inheritance When a thread H attempts to acquire a lock that is

held by a lower-priority thread L, L inherits H’s priority as long as it is holding the lock

Applied transitively if L is waiting for a lock held by a yet-lower-priority thread

Highest lockers (Priority ceiling) While holding a lock, a thread executes at a priority

higher than or equal to that of any thread that needs the lock

-57-

Priority Inversion Example

H is a high-priority thread, M a medium priority thread, and L a low-priority thread

L awakens and starts to run (the other two threads are blocked, waiting for the expiration of delays)

L starts to use a mutually-exclusive resource

• Enters a monitor, locks a mutex H awakens and preempts L

H tries to use the resource held by L and is blocked, thus allowing L to resume

• This priority inversion is necessary M awakens and preempts L

• This “unbounded” priority inversion is evil, since M is indirectly preventing H from running

M completes, and L resumes

L releases the mutually exclusive resource and is preempted by H, which can then use the resource

H releases the resource

H completes execution, allowing L to resume

L completes execution

H

M

L

-58-

Priority Inheritance

L awakens and starts to run at priority L

L starts to use a mutually-exclusive resource

H awakens, preempts L and runs at priority H

H tries to use the resource held by L and is blocked, thus allowing L to resume

• At this point L inherits H’s priority (H)

M awakens but does not preempt L

• This avoids the unbounded priority inversion L releases the mutually exclusive resource, reverts

to its pre-inheritance priority L, and is preempted by H, which can then use the resource

H releases the resource

H completes execution, allowing M (the higher priority of the two ready threads) to execute

M completes, allowing L to resume


Effect of Priority Inheritance A thread holding a lock executes at the maximum

priority of all threads currently requiring that lock

H

M

L

L H L

H H

M

L

H

H

-59-

Priority Ceilings (Highest Lockers)

L awakens and starts to run at priority L

L starts to use a mutually-exclusive resource with ceiling H' > H, and runs at priority H'• This will prevent unbounded priority inversion

H awakens but does not preempt L

M awakens but does not preempt L

L releases the mutually exclusive resource, reverts to its pre-ceiling priority L, and is preempted by H (the higher-priority of the two ready tasks) which then runs at priority H

H starts to use the resource with ceiling H' > H, and runs at priority H'

H releases the resource and reverts to priority H

H completes execution, allowing M (the higher priority of the two ready threads) to execute

M completes, allowing L to resume


Effect of Priority Ceiling A thread holding a lock executes at a priority higher

than that of any thread that might need the lock

H

M

L

L H´H´ H´

L

M

HH´H

-60-

Priority Inversion Avoidance Techniques

Priority InheritanceSupported by many RTOSesOnly change priority when needed (thus no cost in

common case when resource not in use)Thread may be blocked once for each lock that it needs

(“chained blocking”) Implementation may be expensive

• Thread’s priority is being changed as a result of an action external to the task

Ceiling Priorities If no thread can block while holding the lock on a given

shared object, then a queue is not needed for that objectIn effect, the processor is the lockPrevents deadlock (on uniprocessor)

Ensures that a thread is blocked only once each period, by one lower priority thread holding the lock

Fixed ceilings not appropriate for applications where priorities need to change dynamically

Requires check and priority change at each call• Overhead even if object not locked• But this is inconsequential in the queueless case

If ceiling high, effect disabling thread switching

Both sacrifice responsiveness for predictability A thread may be prevented from running in order to

guarantee that deadlines are met overall

-61-

Java for Real-Time Programming:Language Features and Issues

Scheduling/priorities sleep(millis) suspends the calling thread Priority is in range 1..10 Thread can change or interrogate its own or another

thread’s priority yield() gives up the processor

Thread model Priority range (1..10) too narrow Priority semantics are implementation dependent and

fail to prevent unbounded priority inversion Relative sleep() not sufficient for periodicity

Memory management Predictable, efficient garbage collection appropriate

for real-time applications is not (yet) in the mainstream

Java lacks stack-based objects (arrays and class instances)

Heap used for exceptions thrown implicitly as an effect of other operations

Run-time semantics Dynamic class loading is expensive, and it is not easy

to see when it will occur Array initializers run-time code

OOP for real-time programming? Dynamic binding complicates analyzability Garbage Collection defeats predictability

-62-

Regular Java Semantics for Scheduling

Section 17.12 of the Java Language Specification “Every thread has a priority. When there is

competition for processing resources, threads with higher priority are generally executed in preference to threads with lower priority. Such preference is not, however, a guarantee that the highest priority thread will always be running, and thread priorities cannot be used to reliably implement mutual exclusion.”

Problems for real-time applications This rule makes it impossible to guarantee

that deadlines will be met for periodic threads No guarantee that priority is used for

selecting a thread to unblock when a lock is released• No prevention of priority inversion• High priority thread may be blocked for

longer than desired when it is waiting to acquire a lock

No guarantee that priority is used for selecting which thread is awakened by a notify(), or which thread awakened by notifyAll() is selected to run

-63-

Garbage Collection andReal-Time Programming

No Garbage Collection Require that all allocations be performed at system

initialization Common in many kinds of real-time applications Difficult in Java since all non-primitive data are

dynamically allocated

Real-Time Garbage Collector Techniques exist that have predictable / bounded

costs• Incremental or concurrent, vs. mark-sweep

But programmer still needs to ensure that allocation rate does not exceed rate at which GC can reclaim space

Also, in the absence of specialized hardware, such techniques tend to introduce high latencies• GC needs to run at high priority or with the heap

locked, to prevent an application thread from referencing an inconsistent heap

Hybrid approach For low latency, allow a thread to preempt GC if the

thread never references the heap• In absence of optimization, need run-time check

on each heap reference Allow a thread to allocate objects in a scope-

associated area• Area flushed at end of scope/thread

-64-

Real-Time Specification for Java - Scheduling and Priority Support (1)

Basics Class RealtimeThread extends java.lang.Thread Flexible scheduling framework + default scheduler +

priority inversion avoidance

Memory management Garbage-Collected heap Immortal memory Scoped memory Assignment rules prevent dangling references NoheapRealtimeThread can preempt GC

Initial default scheduler At least 28 distinct priority values, beyond the 10 for

regular Java threads Fixed-priority preemptive, FIFO within priority Implementation defines where in ready queue a

preempted thread goes User may replace with a different scheduler

General concept of schedulable object Classes RealtimeThread, NoHeapRealtimeThread, AsyncEventHandler

Constructors for these classes take different kinds of “parameters” objects • SchedulingParameters (priority, importance)• ReleaseParameters (cost, deadline, period, ...)• MemoryParameters (memory area, ...)

Kinds of memory areas

-65-

Real-Time Specification for Java - Scheduling and Priority Support (2)

Priority Inversion avoidance Priority inheritance protocol by default for

synchronization locks Priority ceiling emulation (with queuing) also available Programmer can set monitor control either locally

(per object) or globally Synchronization between no-heap real-time threads

and regular Java threads needs some care• Use non-blocking queues

Support for feasibility analysis Implementation can use data in “parameters” objects

to determine if a set of schedulable objects can satisfy some constraint• Example: Rate-Monotonic Analysis

Methods to add/remove a schedulable object to/from feasibility analysis

Implementation not required to support feasibility analysis

Flexibility Implementation can install arbitrary scheduling

algorithms and feasibility analysis Users can replace these dynamically, can have

different schedulers for different schedulable objects

-66-

J-Consortium’s Real-Time Core Extensions - Scheduling and Priority

SupportConcurrency Class CoreTask (method work()) Thread.run Fixed-priority preemptive scheduler + priority inversion

avoidance

Memory management GC heap for baseline objects, non-GC “allocation

contexts” for Core objects Per-task allocation context, implicitly freed On-the-fly allocation contexts, explicitly freed Stackable objects

Base scheduler 128 task priorities, above the 10 from regular Java Fixed-priority, preemptive dispatching Timeslicing allowed within highest priority

Priority inversion avoidance Priority Inheritance for regular synchronized code Priority Ceiling (without queues) for synchronization on

objects whose classes implement the PCP interface (blocking not allowed)

Priority Inheritance for Mutex objects, which can be locked and unlocked around code that needs mutually exclusive access to some resource

Queue management A task t goes to head of ready queue for its priority when

it is preempted by a higher-priority task, or when it loses inherited priority

-67-

Ada Scheduling / Priority Support(Real-Time Annex)

Priorities Priority range must include at least 30 values, and at least

one higher value for interrupt handlers Dynamic_Priorities package

• Concepts of base versus active priority• Subprograms to set / get a task’s base priority• Deferral of priority changes in certain contexts

Scheduling-related policies - per partition (program) pragma Dispatching_Policy(policy-id) affects selection of

which ready task to run• FIFO_Within_Priority

•Run until blocked or preempted• Implies Ceiling_Locking locking policy•Preempted task, or task which loses inherited

priority, or task whose timeslice expires, goes to head of ready queue

• Default dispatching policy not specified pragma Locking policy(policy-id) for priority inversion

avoidance on protected objects• Ceiling_Locking• Default locking policy implementation defined

pragma Queuing_Policy(policy-id) for entry queues• FIFO_Queuing (default)• Priority_Queuing

Implementation may add further policies “delay 0.0;” yield processor (scheduling point)

-68-

POSIX Scheduling / Priority Support

Real-time scheduling is optional facility Check if _POSIX_THREAD_PRIORITY_SCHEDULING is

defined If so, then struct sched_param structure is provided,

with at least a sched_priority member

Scheduling policies SCHED_FIFO run until blocked or higher priority

thread is ready, FIFO within highest priority SCHED_RR similar to SCHED_FIFO but with time slice

(“round robin” within highest priority) SCHED_OTHER implementation defined

Basic properties Priority range is implementation defined Set a thread’s scheduling policy / priority on

creation (via attribute) and/or dynamically When creating a thread, set the inheritsched

attribute to control whether scheduling properties are inherited from creator

With SCHED_FIFO or SCHED_RR, priority dictates which ready thread runs, including after a mutex is unlocked or a condition variable is signaled or broadcast

Other properties pthread_yield voluntarily relinquishes processor Contention scope: system vs process Allocation domain: relevant for multiprocessors

-69-

Priority Inversion Avoidance in POSIX

Optionally provided support for priority ceiling and priority inheritance protocols, for mutexes Set protocol in an attribute that is passed to a mutex

creation function

Priority Ceiling Protocol Available if _POSIX_THREAD_PRIO_PROTECT defined Set priority ceiling in attribute passed to mutex

creation function• Ceiling should be >= priority of any locker

Locker at priority <= ceiling runs at ceiling priority while holding lock

Locker at priority > ceiling runs at own priority but may get priority inversion

Ceiling can be reset dynamically

Priority Inheritance Protocol Available if _POSIX_THREAD_PRIO_INHERIT defined A mutex locker’s priority is boosted dynamically to

the priority of a higher priority thread that attempts to lock the mutex, and is reset when the mutex is unlocked

Transitive if the lock holder is itself blocked on another mutex

These protocols apply only to mutexes and not to condition variables or semaphores No “owner” of a condition variable or semaphore

-70-

Clock- and Time-Related Features (1)

Time and clock (range, granularity) Java

• JLS•System.currentTimeMillis() returns milliseconds

(long) since epoch•Range is epoch (00:00:00 UTC, 1/1/1970) 263

milliseconds• RTSJ

•HighResolutionTime measured in (long milliseconds, int nanoseconds) and subclasses for AbsoluteTime (relative to epoch), RelativeTime, RationalTime

•Support for multiple clocks• J-Consortium

•Time represented as long (nanoseconds) relative to most recent system start

Ada• Ada.Real_Time.Time reflects monotonically non-

decreasing time values since implementation-defined origin (“epoch”)

• Range of time values must be at least from program start to 50 years later

• Clock tick 1msec, time unit 20 sec POSIX

• Time value structure: seconds and nanosec• Realtime clock requires 20 msec resolution

-71-


Delay / sleep Java

• JLS•Relative sleep methods Thread.sleep(),

taking a long (millis) or a long (millis) and an int (nanos)

• RTJEG•Overloadings of sleep() taking a HighResolutionTime (which may be absolute)

• J-Consortium•Absolute sleepUntil(Time time) method

Ada• delay expr; relative delay, where expr is of

type Duration• delay until expr; absolute delay, where expr is of a time type

POSIX• Relative delay viaunsigned int sleep(unsigned int seconds ) which suspends for seconds seconds

• Returns 0 if suspended for the specified duration, else the time remaining (if awakened by a signal)

-72-


Timeout Java

• Timeouts allowed on wait, join (but not on entering synchronized code)

Ada• Timeouts (including “conditional” calls that

check and continue without blocking) allowed on entry calls, but not for acquiring a lock

POSIX• Timeouts on wait and join

Periodic / sporadic real-time tasks / threads Java

• RTJEG•Via release parameters for real-time

thread constructor, with control over deadline miss / budget overrun

• J-Consortium•Via event handlers

Ada• Via loop on absolute delay (or rendezvous

from dispatching task) POSIX

• Via loop on relative sleep method

-73-

Periodic RealtimeThread in Real-Time Specification for Java

class Position{ double x, y; }

class Sensor extends RealtimeThread{ final Position ps; Sensor(Position p){ super( new PriorityParameters( PriorityScheduler.instance().getMinPriority() + 15 ), new PeriodicParameters( null, // when to start (null means now) new RelativeTime(100, 0), // 100 ms period new RelativeTime(20, 0), // 20 ms cost new RelativeTime(90, 0), // 90 ms deadline null, // no overrun handler null ) // no miss handler ); ps = p; } public void run(){ while ( true ){ double x = InputPort.read(1); // application class double y = InputPort.read(2); // application class synchronized(ps){ ps.x=x; ps.y=y;} // update position try { this.waitForNextPeriod(); } catch (InterruptedException e) { return; } } }}class Test{ public static void main(String[] args){ Position p = new Position(); Sensor s = new Sensor(p); s.start(); ... s.interrupt(); // terminate s }}

-74-

Periodic Task in Ada

type Proc_Ref is access procedure;

task type Periodic is entry Init(Prio : System.Priority; Period : Ada.Real_Time.Time_Span; Action : Proc_Ref; Start : Ada.Real_Time.Time);end Periodic;

task body Periodic is Prio : System.Priority; Period : Ada.Real_Time.Time_Span; Action : Proc_Ref; Next_Time : Time;begin accept Init(Prio : System.Priority; Period : Ada.Real_Time.Time_Span; Action : Proc_Ref; Start : Ada.Real_Time.Time) do Periodic.Prio := Prio; Periodic.Period := Period; Periodic.Action := Proc_Ref; Next_Time := Start; end Init; Set_Priority(Prio); loop delay until Next_Time; Action.all; Next_Time := Next_Time + Period; end loop;end Periodic;

-75-

Other Real-Time SupportJava RTJEG

• Access to raw memory, physical memory J-Consortium

• Low-Level I/O• Unsigned integer conversions /

comparisons

Ada Storage management

• Not an issue as in Java, since GC not required

• Programmer can arrange reclamation via Unchecked_Deallocation or memory pools

• Controlled types (user-defined finalization) possible but may compromise predictability

Restrictions that facilitate more efficient or high-integrity run-time library

POSIX Control over per process or per system

thread contention Process-oriented concurrency mechanisms

-76-

Comparison of Real-Time Support

Points of difference Real-time scheduling support is optional for a

POSIX implementation RTSJ provides an extensible framework J-Consortium spec provides flexible

scheduling options Both sets of real-time Java extensions need to

cope with storage management, what to do about garbage collection

Methodology / reliability All address priority inversion “Absolute” delay in Ada and the two RT Java

specs helps meet deadlines

Flexibility / generality Ada not as general as POSIX or the real-time

Java specs• Policies are partition-wide• Focus on priority ceiling protocol

Efficiency Ada’s queueless protected objects can be

implemented efficiently Generality of RTSJ comes at run-time cost

-77-

Conclusions - Ada

Advantages Software engineering

• Portability / standardization• Encapsulation• Abort-deferred region

Flexibility• Comprehensive / general set of features• Only one of the three languages to include

rendezvous Practical concerns

• Implementations exist• Efficiency

Disadvantages Ada not as popular as other languages Some run-time error conditions not required

to be detected Common idioms should be in standard Conservative mechanisms may be restrictive

• Per-partition scheduling policies• Non-blocking protected operations

-78-

Conclusions - Java

Advantages Language popularity Applicable to dynamic real-time domains RTJEG

• Flexible, dynamic scheduling framework• Support for periodic activities with overrun /

miss detection and handling, async events• Control over memory areas

J Consortium• Good performance• Certain constructs require analyzable code

Disadvantages Not a standard Real-Time support not yet implemented Performance questions Requires programmer to pay attention to

memory allocations RTJEG

• ATC is complex J Consortium

• Model is not easy to grasp (kernel-like facilities external to Java Virtual Machine)

• Relationship to the Java language not clear

-79-

Conclusions - POSIX and Recommendations

Advantages Language independent, in principle Implementations exist Attention to resource cleanup Flexible approach to thread cancellation C-based spec has large potential audience

Disadvantages Many opportunities for undetected errors

• Dangling references• Type mismatches (casts to/from void*)

Nonportabilities• Implementation dependences• Optional or incompatibly supported features

Clash of process and thread oriented features

Bottom line- If you need something that works today: Ada or

POSIX If you need something that reduces the likelihood

of undetected programmer error: Ada or Java If you need something in wide use: POSIX (and

perhaps some day one of the Java RT specs) If you need code portability: Ada or Java If you need something flexible / dynamic: Java

(especially the RTSJ)

-80-

References (1)

General

A. Burns and A. Wellings; Real-Time Systems and Programming Languages (3rd ed.); Addison Wesley, 2001; ISBN 0-201-72988-1

Comparison Papers B. Brosgol and B. Dobbing; “Real-Time Converg-

ence of Ada and Java”; Proc. of SIGAda 2001 Conference, Bloomington, MN; October 2001

B. Brosgol; “A Comparison of the Concurrency and Real-Time Features of Ada and Java”; Proc. of Ada UK Conference, Bristol, UK; October 1998.

Ada Ada 95 Reference Manual, International Standard

ANSI/ISO/IEC-8652:1995; Jan. 1995 Ada 95 Rationale (The Language, The Standard

Libraries); January 1995 J. Barnes; Programming in Ada 95 (2nd ed.);

Addison-Wesley, 1998; ISBN 0-201-34293-6 Current research reported in proceedings of

annual ACM SIGAda and Ada Europe Conferences General Ada Web site: www.acm.org/sigada

Best overallresource

-81-

References (2)

Java J. Gosling, B. Joy, G. Steele, G. Bracha; The

Java Language Specification (2nd ed.); Addison Wesley, 2000; ISBN 0-201-31008-2.

S. Oaks and H. Wong; Java Threads (2nd edition); O’Reilly, 1999; ISBN 1-56592-418-5.

D. Lea; Concurrent Programming in Java (2nd ed.); Addison Wesley; 2000; ISBN 0-201-31009-0

G. Bollella, J. Gosling, B. Brosgol, P. Dibble, S. Furr, D. Hardin, M. Turnbull; The Real-Time Specification for Java; Addison Wesley, 2000; ISBN 0-201-70323-8

International J Consortium Specification; Real-Time Core Extensions, Draft 1.0.14, September 2000. Available at www.j-consortium.org

POSIX ISO/IEC 9945-1: 1996 (ANSI/IEEE Standard

1003.1, 1996 Edition); POSIX Part 1: System Application Program Interface (API) [C Language]

D. Butenhof; Programming with POSIX Threads; Addison Wesley, 1997; ISBN 0-201-63392-2

concurrency and real-time programming support in java™, ada and posix

Documents

java realtime

class java

java preliminariessmalltalk

java jconsortiumada

crealtime extensions

realtime extensionssun

threada thread

processperthread resources