Parallelization!
Rasmus Buchmann & Maximilian Klein
A simple example to start with
Start and stop...
Thread 1
running = true;
n = 0;
startThread2();
while(running){
n = n+1;
}
|
|
Start and stop...
Thread 1
running = true;
n = 0;
startThread2();
while(running){
n = n+1;
}
|
Thread 2
running = false;
|
Start and stop...
Lets look at it...
Start and stop...
If it stops (might) depend on
- Programming Language
- Compiler Options
- CPU Behaviour
Start and stop...
If it stops (might) depend on
- Programming Language
- Compiler Options
- CPU Behaviour
- Runtime... (On runtime optimized languages...)
- CPU Cache size
- Loop-Length
- System Scheduler
- Operating System
But..
There are methods to avoid these issues!
But..
You can learn those!
Do you really believe everybody uses them correctly?
locking [...] That's something I've done a lot of [...] and I'm tired of trying to get it right, because it's simply far too difficult.
Rich Hickey, Clojure Concurrency
The Actor Model
No locking necessary
The Actor Model
No locking necessary
Actors are
- Individual computation units
- Communiction units
Actors compute each message serially
Actors can simultaneously
- Send messages
- Create new actors
- Designate what happens with messages
No strict message ordering!
The messaging is asynchronous
No strict message ordering!
But...
No strict message ordering!
But... there are some rules
Activation Ordering (Hewitt, 2006)
- Causality is preserved
- Relativistic Invariance
$\Rightarrow$ other nodes see the same causality
Arrival Ordering
(Hewitt, 2006)
It's guaranteed that two consecutive messages from actor A to actor B will arrive in that order!
A programming language based on actors
(designed 1986 by Ericcson)
This is NO Erlang programming lecture
Generally speaking:
You design actors in Erlang and link them together
Erlang has some nice features!
Erlang is functional
In some parts it is pure
(e.g single assignment)
Erlang discourages:
Incidental or hidden state
Usually the state are the messages and the actor network
Hot swapping
Exchange a part of the code on the fly
Hot swapping
Simply exchange an actor
Hot swapping
State is encoded in messages
Hot swapping
Actor computation is referentially transparent
Hot swapping
Erlang has a way of abstracting actor "adresses"
("adresses" are usually called process IDs in Erlang)
Erlang is fault tolerant
"Let it crash!"
Erlang is fault tolerant
If an actor crashes you can simply restart it
Erlang is fault tolerant
System doesn't stop on crashes!
Erlang is fault tolerant
Is able to work even if parts changed and you weren't prepared
Erlang reduces controlflow complexity
Erlang is not the key to everything!
Where to use
In communication problems (Chat/Telephony/etc.)
Where not to use
Embarassingly parallel problems
(Nearly no communication required)
Other interesting ideas
CSP = Communicating Sequential processes
CSP differences
Communication annonymously via channels
This can be a huge advantage!
CSP differences
Channels are not asynchronous
Transmission and reception must happen at the same time
CSP Languages
- Occam (first of its kind, 1983)
- Go (Googles language)
- Clojure (with async)
CSP Languages
- Occam (first of its kind, 1983) Ugly
- Go (Googles language)
- Clojure (with async)
CSP Languages
- Occam (first of its kind, 1983) Ugly
- Go (Googles language)
- Clojure (with async) Immutability!
Why Immutability?
It cannot go wrong if the processes can't change anything
Immutability is strange...
You have to think differently
Thank you for your attention!
Next presentation
Topic: Buggy?!
