Download PPT - School of Computer Science

CPIJ – Lecture Notes
1.2 - Objects and Concurrency
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
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).
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.
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.

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.

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.
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.
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.
Object Models and Mappings
The 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.
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.