Interaction, Concurrency & OOP in the Curriculum

A Second-Year Course

OOPSLA 1998 Educators’ Symposium

Christopher Colby Radha Jagadeesan

Konstantin Läufer Chandra Sekharan

Loyola University Chicago

Dept. of Mathematical and Computer Sciences

6525 N Sheridan Road

Chicago, Illinois 60626, USA

{colby,radha,laufer,chandra}@cs.luc.edu

http://www.cs.luc.edu/triveni/

3

Abstract

We argue that a computer-science curriculum should introduce the principles of concurrent programming in an integrated, coherent, and

application-independent fashion early in the major. We have incorporated current research into our

curriculum. We describe a second-year course on the fundamentals of concurrent and interactive programming that is the fruit of this work. We

offered this course to about 90 students in Fall 1997, Spring 1998, and Fall 1998.

4

The world is full of concurrent systems

• real-time systems• signal-processing systems• telecommunication systems• graphical user interfaces• operating systems• multiprocessors and pipelining• distributed systems

5

What is wrong?

How do students learn to build concurrent systems?

6

How sequential programming is usually taught

• At the foundation level• In introductory courses:

– structured programming– data abstraction– object-oriented programming– functional programming

• As a means for problem-solving

7

How concurrent programming is usually taught

• At the application level• In advanced courses:

– operating systems: threads in Nachos– networks: concurrency used in protocols– software engineering: concurrency in GUIs– computer architecture: concurrency in HW

• Not as a means, but as an end

8

A better approach: A new intro course in concurrency

• taught early in curriculum (second year)

• based on our current research in concurrency (Triveni)

• integrated

• coherent

• application-independent

9

Advantages• Programming methodology

– conceptual decomposition into concurrent modules

– pedagogically beneficial to expose students to concurrency before sequential programming becomes their primary way of thinking

• Specification, testing, verification– formal methods taught as an integral part of the

programming process– concurrent programming suitable motivation

10

Main ideas in concurrent programming

• Reactivity– systems are event-driven– systems interact continuously with environment– execution as bursts of activity in response to

events

• Asynchrony– processes loosely coupled– communication can take arbitrary time

11

Relevant research in concurrent programming

• Process algebras and synchronous programming languages– notion of abstract behavior– combinators on behaviors

• Temporal logic, testing, and verification– verifiable properties of reactive systems– automated verification based on model checking

12

Our course:

Introduction to Concurrency

13

Running theme: Battle game

• n-player variation of 2-player Battleship

• Oceans: each player has a collection of ships on one of n disjoint ocean grids

• Ships: each ship occupies a rectangular subgrid of a player’s ocean– battleships stay on surface, submarines can dive

• Moves: a player can move as fast as the user interface or his/her reflexes allow– shoot, move ship, dive submarine, raise shield

14

Interaction and concurrency and OOP in Battle

• Concurrency– decomposition: game into players and central

controller– abstraction: over nonessential dependencies among

independent user events– other issues: e.g. priorities

• OOP– inheritance for extending concurrent behavior:

submarine is-a ship with diving capabilities

15

Program correctness in Battle

• Safety properties: consistency– concurrent access to shared data: state of each

player

• Liveness properties: progress– each player must have a chance to proceed– actions of each player must eventually reach

controller and other players

• Nondeterminism: lack of repeatability– timing of shot vs. move

16

Integration into our curriculum• First year:

– CS170: Structured programming (now in Java)– CS271: Data structures (soon in Java)

• Second year:– CS272: Object-oriented prog. (Java/C++)– CS211: Discrete structures (FSMs, induction)– CS275: Computer architecture

• Prerequisites for Intro to Concurrency– CS272 and CS211– ensures data structures, algorithms, OOP, Java

17

Course modules

• (1) Specification– temporal logic– automata as specifications– generating test cases from specifications

• (2) Design of concurrent and interactive programs– process algebras– parallel composition as structuring mechanism– preemption: termination, suspension, interrupts

18

Course modules (cont.)

• (3) Case studies in Triveni

• (4) Implementation of concurrent programming languages– automata as abstractions of interaction– thread programming for managing concurrency

19

Programming assignments

• (1) Implement simple 2-player version of Battle using Java AWT– aim: intro to events and event handlers

• (2) Implement a framework for FSMs with combinators– aim: intro FSMs as abstractions of controllers

• (3) Implement a full-scale version of battle (group project)– aim: decomposition, temporal logic specs

20

Results and future work

• Course well-received and successful

• Now integral component of our undergraduate curriculum as an elective

• Considering migrating some modules into CS272 and CS375 (Software Engineering)

• Investigating idea of more in-depth two-semester sequence

• Investigating idea of introducing concurrency in first year

21

Our research contribution:

Triveni

A component model for concurrent programming with threads and events

22

Triveni: Overview• A component model for concurrent

programming that integrates:– thread-based programming (e.g. Java threads)– event-based programming– object-oriented programming

• Based on process algebras and synchronous programming languages

• Realized as a Java API - JavaTriveni library

• Joint work with Lalita J. Jagadeesan & Carlos Puchol, Bell Labs, Lucent Technologies

23

Motivation • Process algebras (e.g. CCS, CSP) and

synchronous programming (e.g. Esterel, Lustre, Statecharts)– key feature: notion of abstract behavior

• In a concurrent system, essentially the interaction of the system with its environment

– program combinators operate on behaviors and yield behaviors

– communication is via labeled events (that are abstractions of names of communication channels)

24

Triveni: Computational Model

objectsin host lang

Triveni process:finite state machine events

25

Basic Principle 1: Behaviors

• Programs can be combined freely with Triveni combinators– one need only be concerned about the desired

effects on the resulting behavior– implementation of Triveni yields the correct

combination of behaviors

26

The Triveni Combinators

• emit e, await e -> P, present e then P

• switch-valuator(e)

• rename [e1’/e1, e2’/e2, ...] in P

• local e1, e2, ... in P

• do P watching e, suspend P on e1 resume e2

• P1 || P2 (parallel composition)

• loop P, P1 ; P2 (seq. composition), done

• activity (code in host lang)

27

Basic Principle 1a: Parallel Composition

• Parallel composition can be used freely for the modular decomposition of designs– parallel-composed programs indistinguishable

from simple programs– correct wiring among events sent by parallel

components is done automatically by Triveni• implementation of program can closely reflect

design

• each parallel component can be implemented separately: Triveni realizes desired communication

28

Example: 5ESS Carrier Group Alarms

CollectionSoft ||RENAME [req1/req,resp1/resp] IN DataSoft1||…||RENAME [reqk/req,respk/resp] IN DataSoftk

Triveni pseudocode

summary requests

CGA Data1 CGA Data3CGA Data2

CGA Collection

req1 resp2 req3 resp3req1resp1restart restart

data to HMI

29

Basic Principle 1b: Preemption

• Exceptions are supported via preemption combinators– example: DO P WATCHING e– aid in program modularity

• Exceptions have first-class status– any event can be used in place of e

30

ExampleDataSoft = LOOP

DO AWAIT req ->

// collect threshold amount of data from beginning of database

EMIT resp(data); LOOP

AWAIT req -> // collect threshold amount of data from rest of database

EMIT resp(data);

WATCHING restart

Note: Event priorities achieved by nesting of preemption combinators restart has higher priority than req

31

Basic Principle 2: Integration

• Triveni is compatible with existing work in programming languages and concurrent systems– integration of previous principles with OOP– compatible with existing threads standards (e.g.

Java threads, Posix threads)– compatible with event models based on event

multicast patterns (e.g. Java Beans)– specification-based testing: automates testing of

safety properties

32

• Integration with OO Programming– Triveni processes are objects with enriched

state• reactive: interaction with environment via events

– communication with environment via event multicast

• autonomous: system clocks, timers– communication with environment via thread operations

– any objects that conform to these general requirements can be used as Triveni processes

Basic Principle 2a: Processes as Objects

33

Basic Principle 2b:Specification-based Testing

• Non-intrusive form of testing/debugging• Safety properties written in temporal logic

– all execution sequences that satisfy property

• Safety property (negation) automatically translated into a Triveni process

• Alerts user if property violated during a run of the system

• Example: No summary request should be honored when another one is running

34

Some Implementation Issues Handled by Triveni

• Parallel composition:– multiplicity of threads is hidden– fair scheduling

• Event multicast– atomicity of events– all parallel components see same event ordering– local events are hidden from components

outside their scope

35

JavaTriveni Implementation

• Implementation based on Petri Nets

• Java class library: – integrated with Java threads and objects– event model compatible with Java Beans

• Supports specification-based testing

• Formal semantic foundation for compositionality and fairness

36

5ESS Carrier Group Alarms Software

• Carrier groups are the connections between switches– malfunctions can result in disturbances in

telephone calls

• 5ESS Carrier Group Alarms Software responsible for reporting status changes on carrier groups

• Earlier case study: re-implemented CGA Software in Esterel programming language

37

JavaTriveni case study

• Re-implemented CGA Software in JavaTriveni– hierarchically nested parallel components– about 2500 lines of JavaTriveni code

summary requests

CGA Data1 CGA Data3CGA Data2

CGA Collection

req1 resp2 req3 resp3req1resp1restart restart

data to HMI

38

JavaTriveni case study (cont.)• Extensively used Triveni design principles

– JavaTriveni combinators– modularity in design and implementation greatly

aided by parallel composition and preemption operators

– objects + renaming + inheritance gives a convenient way to express variances

• Used specification-based testing to check whether CGA implementation satisfied some safety properties

39

Current and future Work

• Interaction of preemption and induced JavaTriveni priorities with Java exceptions and priorities

• Integration of JavaTriveni with distributed programming - Remote Method Invocation (RMI)

• Investigation of mobility

• More applications (e.g. user interfaces, interactive web services)