Adding Concurrency to a Programming Language Peter A. Buhr and Glen Ditchfield USENIX C++ Technical Conference, Portland, Oregon, U. S. A., August 1992 A Review by Keith Schoby Midwestern State University June 27, 2005

Topics  Background and overview  Concurrency elementary execution properties  Design options  Concurrency libraries  Task libraries for object-oriented languages  Conclusions

Background  For users to make the additional effort to design and write concurrent programs: Complexity required must be low Performance payback must be large  To be useful in a parallel environment: New programming languages must provide concurrency Existing programming languages must be augmented with concurrency

Overview  A programming language that lacks facilities for concurrent programming can gain those facilities in two ways The language can be extended with additional constructs, which will reflect a particular model of concurrency Libraries of types and routines can be written with different libraries implementing different models.  These two approaches for both objected-oriented and non- object-oriented languages are examined Purpose: determine if the fundamental aspects of concurrency can be provided through generally available language constructs, or if concurrency requires languages to be augmented with additional constructs. Note: For brevity, this presentation only considers OO issues.

µC++  Developed by authors; freely available  Adds concurrency to C++  Criticized for extending language rather than using existing language features  Authors feel it is not possible to add concurrency with existing features without sacrificing essential features of concurrency

Elementary Execution Properties  Three elementary execution properties of concurrency A thread sequentially executes statements An execution-state is the state information needed to permit concurrent execution Mutual exclusion gives a thread sole access to a resource for a period of time  First two represent minimum needed to perform execution and are not expressible in machine- independent or language-independent ways

Design Options  Form of a task  Form of communication  Static type-checking  Declaration scopes  Direct and indirect communication  Synchronization and mutual exclusion  Synchronous or asynchronous communication  Order of processing requests “We reject any solutions to these options that involve coding conventions or multi-step protocols because such solutions are error-prone both to implement and maintain.”

Concurrency Libraries  Assuming some primitive mechanisms already exist to provide the three elementary execution properties, the following problems must be addressed: Starting a library Context switching General library routines I/O libraries Abnormal event handling

Starting a Library  Must ensure that library is initialized before objects depending on it are instantiated Forbid the declaration of library objects with static storage duration – too restrictive Test repeatedly to ensure proper order is maintained – too inefficient Declare instance of library initialization object before any declarations that depend on it in each translation unit

Context Switching  C and C++: setjmp / longjmp Save and restore execution state Sometimes used as basis for context switching Inefficient  Saving floating-point registers and other task-specific data substantially increases cost of context switches  Significant concern since many tasks do not use such registers  User usually required to state whether to save floating point registers (error-prone)

General Runtime Libraries  Most UNIX library routines are not reentrant  One solution: supply cover routines for each non- reentrant routine to guarantee mutual exclusion Not practical as it would require too many cover routines  Another solution: pre-empt only in user code If task is in user code, perform context switch If task is not, reset the timer and return Problem: task may never be pre-empted Sufficient for uniprocessor  Future: all library routines must be reentrant

I/O Libraries  Task must not execute an operation that causes processor on which it is executing to block Poll for I/O completions Possibly block the program if all tasks are directly or indirectly blocked waiting for I/O operations to complete  Most concurrency libraries provide nonblocking versions of the I/O routines

Abnormal Event Handling  Cannot be done properly using library mechanisms  New programming languages provide facilities such as exceptions Concurrency adds complexity  How does exception handling work with multiple execution states?  How are hardware and software interrupt facilities introduced?

Abnormal Event Handling  Two distinct mechanisms identified An exceptional change in control flow, using the stack of an execution-state (i.e., C++ style exceptions) A corrective action by an intervention in the normal computation of an operation, which includes interrupt/signal handling between tasks  “Our conclusion after constructing an abnormal event library is that it is impossible to provide powerful abnormal event handling mechanisms without augmenting the programming language.”

Task Libraries for OO Languages  Abstract class, Task Constructor – creates thread User-defined task classes inherit from Task  Tasks are objects of these classes Approach used to define C++ libraries for simple parallel facilities  Task classes – same properties as other classes  Tasks – same properties as other objects

Lifetime of a Task Object  Thread creation for the task  Task initialization  Task body execution, which controls synchronization with other tasks  Task termination  Joining/synchronization by another task with a task that is terminating

Conclusions  Concurrency is a fundamental aspect of a programming language that cannot be built easily from primitive non- concurrent language constructs.  If a language supports all the design options presented at the beginning, a large number of different models of concurrency can be implemented. Usually, the expressive power of the language is the limiting factor as to how well a model can be expressed.  Minimizing the cost of a context switch requires language support because only the compiler knows exactly how much state a particular object is using.

Conclusions  Without language support, object-oriented languages with inheritance have problems in coordinating initialization and the starting of a task’s new thread, as well as specifying the location where the thread starts execution.  A language’s exception handling mechanism must be designed to work with its concurrency mechanism because exceptions work with the stack associated with an execution-state (exceptions search the execution stack) and there are now multiple execution-states. Furthermore, a mechanism to deal with interrupts must be provided.