Just Keep Passing the Messages from Groovy and Grails eXchange 2011

Just Keep Passing
the Messages

Dr Russel Winder

It’z Interactive Ltd
russel@itzinteractive.com
@russel_winder
Copyright © 2011 Russel Winder 1

Just Keep Passing
the Messages

Dr Russel Winder

Independent Consultant
russel@russel.org.uk
@russel_winder

Just Keep Passing
the Messages

Prof Russel Winder

Wolverhampton University
russel@russel.org.uk
@russel_winder

Aims and Objectives

● Investigate why message passing architectures are the
software architectures of the future.
● Showcase GPars as the framework for concurrency
and parallelism on the JVM.
● Have some fun (whilst hopefully learning something).


Structure of the Session

● Introduction.
● Do stuff.
● Exit stage (left|right|front|back).

There may well be significant
dynamic binding of the session.


Protocol

● Some slides, to kick things off.
● Some programs to really demonstrate things.

● NB Interaction between audience and presenter is
probably mandatory.

We reserve the right to (shelve|stash) for
later any interaction that appears to go
on longer than seems appropriate.

NB This is a 44.99min session!

Audience Aims and Objectives

?

BEGIN

● History is important:
– To know today, we look to yesterday. To know tomorrow,
we see today as yesterday.
http://wiki.answers.com/Q/Why_history_is_important
–


Processes / Threads Processes / RPC

Threads / Shared memory

Processes / IPC

Multi-tasking

One program at a time.


Historical Summary

● Shared-memory multi-threading for applications
programming is a total aberration:
– Consequences of operating systems handling of
concurrency have been imposed on all programmers.
● Cooperating processes is where applications
development sanity is:
– Operating system interprocess communication was slow,
hence threads, but this lead directly to the shared-memory,
multi-threading quagmire.
– Erlang has shown that processes and message passing can do
the job properly even after the “mainstream” had rejected
process-based working.


Concurrency
vs.
Parallelism


Concurrency

● Running multiple tasks using time-division
multiplexing on a single processor.


Parallelism

● Running multiple tasks concurrently.

Note that the word concurrency here is the English
meaning whereas the previous slide gave the
computing jargon meaning of the word.


Concurrency . . .

● . . . is a technique required for operating systems.
● . . . can sometimes be required for applications but
not as much as might be thought.

● Applications can use alternative models, for example
event-driven systems.
– Abstract over the control flow rather than manage it with
locks, semaphores, monitors, etc.


Parallelism . . .

● . . . is about making an algorithm execute more
quickly in the presence of multiple processors.
● . . . is an architectural and design issue for
applications.


Concurrency

● The problem with threads is shared memory:
– Without writeable shared memory there is no need for
synchronization.
● Why impose a 1960s, operating system driven view of
concurrency management on applications
programmers?


Mutable Shared Memory is . . .

● . . . anathema to parallelism.
● . . . anathema to concurrency.
● . . . anathema to modern applications programming.
● . . . anathema.


Solution . . .

● . . . do not use mutable shared memory.

Note the caveat here that opens the door
to using shared immutable data.


Operating Systems . . .

● . . . are inherently a concurrency problem.
● Applications on the other hand are not, they
should be using higher level abstractions.


Object
Orientation


Original Model

● Object-based:
– A set of (small) closed namespaces, with methods,
exchanging messages requesting services.
● Object-oriented:
– Object-based plus classes and inheritance


Implementations

● Smalltalk realized the object-oriented model
correctly.
● C++ did not: message passing replaced by function
call.

C++ destroyed correct appreciation of the
object-oriented model of computation.


Non-contentious (sort of) Syllogism

● Object-orientation is
about objects passing
messages to each other:
object-orientation is not
about function call in a ● C++ is not an object-
shared memory context. oriented programming
● C++ is a programming language.
language based on
function call in a shared
memory context: C++
does not have objects
passing messages to
each other.

Java


Object-orientation

● Java follows C++:
– Function call replaces message passing.
● Java beats C++, had threads 15 years before C++.
● Shared memory multi-threading requires all the
locks, semaphores, monitors, etc. and Java has it all.

Java is not an object-oriented language.


Partial Solution for JVM

● Use java.util.concurrent:
– Provides many high-level tools.
– Has many low-level tools.

If you are using the low-level tools then you are lost
to the cause of quality application programming.

Use jsr166y (Fork/Join) and extra166y (ParallelArray) in
preference to using stuff in JDK6.

JDK7 has Fork/Join but not ParallelArray, still have to
use extra166y for this – sadly means using jsr166y.

Interesting Aside

● Paul King at SpringOne2GX 2011:

“Who used synchronized?”
Some in audience raise their hands.
“You did it wrong!”


High Performance
Computing
(HPC)

aka

Real Computing


Parallelism Rules

● HPC has been doing parallelism for 40+ years.
● Combinations of architectures:
– Vector processors
– Multi-bus multiprocessors
– Clusters


HPC Extant Solution

● Message Passing Interface (MPI)

MPI addresses the problem of SPMD or MIMD
parallelism in the context of multiple, possibly
multicore, systems.


HPC Proposed Solution

● Partitioned Global Address Space (PGAS)
● Champions:
– Chapel
– X10
– Fortress

Structure the global address space to allow for
multiple processors sharing a single memory and/or
to deal with distributed memory systems.


Return to a Better Way


Real Solutions?

● Actor Model
● Dataflow architectures
● CSP (Communicating Sequential Processes)

Return to a process and message passing view of applications.

Nothing wrong with threads as a tool.
The problem is using shared memory.


Return to objects passing
messages to each other.

Return to being object-oriented.


Actor Model

● A program is a collection of actors that send
messages to each other.
● An actor is a process with a “mailbox” for receiving
messages.
● A mailbox is a (thread-safe) queue of messages.


Dataflow Model

● A program is a graph of operators with some data
sources and some data sinks.
● An operator is an event-triggered computation with
some inputs and some output.
● An operator triggers for a certain state of its inputs.


CSP is . . .

● . . . mathematics:
VMS = μX. ( in2p → (chocolate → X|out1p → toffee → X)
| in1p → (toffee → X|in1p → (chocolate → X|in1p → STOPαX )))

● . . . but not scary since the mathematics can be
hidden in an API, so it just becomes a programming
tool.


CSP

● A program is a graph of processes running a
sequential computation that take input from input
channels and write output to output channels.
● Data exchange down a channel realizes a rendezvous.


Commentary

● Actors are non-deterministic, with chaotic
communications and hence complex.
● Dataflow and CSP have much greater determinism
with fixed communications channels.


Implementations

● Actor Model:
– JVM: GPars, Scala, Akka, Fantom
– Native: C++/Just::Thread Pro, D
– Alternative: Erlang
● Dataflow Model:
– JVM: GPars, Pervasive DataRush
– Native: C++/Just::Thread Pro
● CSP:
– JVM: GPars, JCSP
– Native: C++CSP2


Acknowledgements


First Example Problem

● Something small, so the code is small.
● Something not too “toy”.
● Something with good parallelism.
– Embarrassingly parallel to allow checking of scaling.




What is the Value of ?

● Easy, it's known exactly, it's  (obviously).

†
It's simples

†
Aleksandr Orlov


Approximating 

● What is it's value represented as a floating point
number?
– We can only obtain an approximation.
– A plethora of possible algorithms to choose from, a popular
one is to employ the following integral equation.

 1 1
=∫0 dx
4 1x 2


One Possible Algorithm

● Use quadrature to estimate the value of the integral
– which is the area under the curve.
4 n 1
= ∑i=1
n i−0.5 2
1 
n

With n = 3 not much
to do, but potentially
lots of error.
Embarrassingly parallel.


Major Minor Hardware Problem

● Multiple hyperthreads per core on multicore
processors can be a serious waste of time.

Ed: Rant about chip manufacturers and
operating systems elided to avoid persecution
prosecution.

Second Example Problem

● Sleeping Barber Problem
– A barber shop has a cutting chair and some waiting chairs.
The barber sleeps in the cutting chair if there are no
customers. If a customer enters, the customer checks the
cutting chair and wakes the barber if the barber is asleep in
the chair, sits in the chair and gets a hair cut. If the
entering customer sees the cutting chair in use, the
customer checks to see if there is a waiting chair free. If
there is the customer sits and waits, otherwise the customer
leaves dissatisfied. On finishing a customer cut, the
customer leaves satisfied (we assume), and the barber
checks for waiting customers. If there are any waiting
customers, the customer moves to the cutting chair. If
there are no waiting customers, the barber returns to
sleeping in the cutting chair.

Sleeping Barber Problem . . .

● . . . is an interesting recasting of a process
synchronization problem in operating systems.
● . . . is due to Edsgar Dykstra

http://en.wikipedia.org/wiki/Sleeping_barber_problem


If the examples haven't been shown
yet, now is the time to show them!


Summary

● Multiprocessor programming is now the norm – even
if you don't actually need it.
● Hardware is rapidly heading towards distributed
memory architectures, instead of shared memory
multi-threading.
● Shared memory multi-threading requires locks,
semaphores, monitors, etc. and programmers find it
hard to get that stuff right.
● Actor Model, Dataflow Model, and CSP are higher
level abstractions of managed control flow that are
easier for programmers to deal with.


Summary of the Summary

● Shared-memory multi-threading is like
stacks, you know it's there, but you just
don't worry about it.


Summary of the Summary of the
Summary
● If you think locks, semaphores, monitors, etc. are
important for your work, you are either working in
the concurrency frameworks business (*) OR you are
doing it wrong.

(*) Which includes operating systems.


END

for ( person in roomContents.collect { x -> if ( x instanceof Human ) x } ) {
person << "Please leave peaceably."
}
println "Goodbye all."


Blatant Advertising

Python for Rookies
Sarah Mount, James Shuttleworth and
Russel Winder
Thomson Learning Now called Cengage Learning.

Developing Java Software Third Edition
Russel Winder and Graham Roberts
Wiley

Buy these books!

Just Keep Passing
the Messages

Dr Russel Winder

It’z Interactive Ltd
russel@itzinteractive.com
@russel_winder

Just Keep Passing the Messages from Groovy and Grails eXchange 2011

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Just Keep Passing the Messages from Groovy and Grails eXchange 2011

Semelhante a Just Keep Passing the Messages from Groovy and Grails eXchange 2011 (20)

Mais de Russel Winder

Mais de Russel Winder (20)

Último

Último (20)

Just Keep Passing the Messages from Groovy and Grails eXchange 2011