CPIJ – Lecture Notes 1.2 - Objects and Concurrency

1. These slides constitute the lecture notes that I (Rob Dempster) prepared to deliver for the COMP718 module (Special Topics ~ Concurrent Programming) at UKZN (PMB Campus) during semester 1, 2010. The presentation of the module is based on the prescribed text: Concurrent Programming in Java ~ Design Principles and Patterns, 2nd Edition by Doug Lea. I have always been fascinated by Concurrent Programming and have taught aspects of the topic during the presentation of Operating Systems, Networking and Distributed Computing modules. When Doug Lea's book appear I bought a copy. A couple of years after that I purchased a second copy with a view to teaching a module based on the book. That never happened whilst employed at UKZN. I only got the opportunity to do so after retiring and grateful for the opportunity to tie up this loose end. Concurrent programming is not easy. I can only hope that you too will find it fascinating. While the advent of multi-core processors on the desktop has brought concrrent programming into the foreground of the computer science curriculum, I doubt that it has made it easier. Studing Douig Lea's book will CPIJ – Lecture Notes1.2 - Objects and Concurrency

2. Concurrency • My definition: A computing system that overlaps two or more distinct computation streams in an environment that supports inter-stream communication and collaboration. • The overlapping may either be: • in real time in terms of the use of multiple processors, usually closely coupled, or • In pseudo real-time in terms of time-sliced scheduling of a single processor. • The communication can be in the form of synchronization and messages. • The collaboration can be in the form of the use of resources in terms of previously agreed protocols. • For Java programs the system is confined to a single JVM. • Java does support Distributed Computing using multiple loosely coupled JVMs by means of Remote Method Invocation (RMI).

3. Reasons for using Concurrency • Best understood in terms of actual examples: • Web Services: support for multiple connections. Also employs Distributed Computing (DC). • Number Crunching: direct support for parallizable computations. Also employs DC. • I/O Processing: probably the first use of concurrency. • Simulation: probably the second longest lived use of concurrency. • GUI-based applications: closely tied to a singly-threaded event handler, but relies on other concurrent services – also improves performance. • Component-based software: Large granularity components belonging to a single system can compute semi-autonomously in a collaborative context. • Mobile Code: Can compute semi-autonomously in a collaborative context on the respective hosts. More easily isolated, monitored and controlled. • Embedded Systems: These systems mostly perform control functions and employ concurrency for performance reasons. With hard real-time systems these must be able to provide performance guarantees. Not really Java's forte.

4. Concurrent Execution Constructs • The following alternatives provide different options in terms of security, protection, fault tolerance, administrative control and associated overheads: • Computer Systems: With large numbers of computers each could run a logical unit of computation: • Maximizes independence and autonomy. • Constructing and managing the system expensive and difficult. • Resource sharing not really possible. • Other difficulties include: • Naming • Security • Fault tolerance • Recovery • Reachability • Only used where a distributed computing solution is required.

5. Concurrent Execution Constructs (cont'd.) • Processes: an operating system (O/S) abstraction representing a unit of execution: • Typically represents a separate running program. • For Java this is the JVM. • O/Ses designed to provide each process with a virtual machine. • Can communicate with interprocess communication (IPC) facilities. • Shared memory (includes semaphores) • Pipes • Signals • Locks (files) • Sockets • Processes much cheaper than per-machine solutions. • Processes less autonomous than per-machine solutions.

6. Concurrent Execution Constructs (cont'd.) • Threads: make further trade-offs in autonomy. The main trade-offs are: • Sharing: memory, files and other single process resources. • Some O/Ses also differentiate between user and kernel threads. • Scheduling: Independence guarantees may also be weakened to support cheaper scheduling policies. • One extreme sees all threads compete within a single threaded process. Running thread runs until it blocks. • At the other extreme all threads contend via a pre-emptive scheduling rules. • The Java language allows all possibilities between these extremes. • Communication: • Threads can use all the options available to Systems and Processes. • Threads can also use cheaper shared memory based strategies such as locks and waiting and notification mechanisms. • Savings must be offset against greater complexity and potential for error.

7. Concurrency and OOP • Simula 67 was the first OOP language. • It was also the first COOP language. • Made use of coroutines. • C , C++ and others followed. C and C++ used libraries (POSIX to support concurrency. • OO design was not a feature of multi-threaded systems programming in the 1970s. • Concurrency did not feature in the embrace of OOP in the 1980s. • COOP now an essential part of programming and this is in part due to popularity and ubiquity of Java.

8. Concurrency and OOP (cont'd.) • While COOP shares many features with programming in general, it differs in critical ways from the following programming paradigms: • Sequential OOP: Non-deterministic and thus intrinsically more difficult. • Event-based programming: • Much in common with GUI event-based programming, but events are queued and processed in a single event loop running on a separate thread. Strategy allows for optimization of event processing. • Concurrent Systems Programming: • Java differs from C in terms of OOP encapsulation, modularity, extensibility, security and safety features otherwise lacking in C. • Concurrency is part of the Java language and Java compiler, C uses libraries (POSIX Threads). • Other concurrent programming languages: • All concurrent programming languages are at some level, equivalent.

9. Object Models and MappingsThe water tank model • Conceptions of objects differ across sequential versus concurrent OO programming and even across different styles of COOP. • To study this we will consider these different programming styles in terms of their underlying object models and mappings. • To do this we will consider the following class that simulates a water tank: class WaterTank { final float capacity; float currentVolume = 0.0f; WaterTank overflow; WaterTank(float cap) { capacity = cap, … } void addWater(float amount) throws OverflowException; void removeWater(float amount) throws UnderflowException; } • The intent here is to simulate a water tank with the following: attributes, invariants, operations, connections, pre- and post-conditions and message protocols.

10. Object Models • Object models provide rules and frameworks for defining objects more generally covering: • Statics – state attributes, connections, local methods and non-local (message) methods. • Encapsulation – internal state only modifiable from object itself! • Communication – only via message passing. • Identity – unique (name) persists for objects life-time. • Connections - • Between known identities using direct method (message) based invocations. • Channel : shared vehicle for possibly anonymous message passing. • Computation - • Accept a message. • Update internal state. • Send a message. • Create a new object.