stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf

State You’re Doing it Wrong:
Alternative Concurrency
Paradigms For the JVM
Jonas Bonér
Crisp AB
blog: http://jonasboner.com
work: http://crisp.se
code: http://github.com/jboner
twitter: jboner

Agenda
> An Emergent Crisis
> State: Identity vs Value
> Shared-State Concurrency
> Software Transactional Memory (STM)
> Message-Passing Concurrency (Actors)
> Dataflow Concurrency
> Wrap up

2

Moore’s Law
> Coined in the 1965 paper by Gordon E. Moore
> The number of transistors is doubling every
18 months
> Processor manufacturers have solved our
problems for years

3

The free lunch is over
> Theend of Moore’s Law
> We can’t squeeze more out of one CPU

5

Conclusion
> This is an emergent crisis
> Multi-processors are here to stay
> We need to learn to take advantage of that
> The world is going concurrent

6

The devil is in
the state

8

Wrong,
let me rephrase

9

The devil is in
the mutable state

10

Definitions
&
Philosophy

11

What is a Value?
A Value is something that
does not change
Discussion based on
http://clojure.org/state
by Rich Hickey

12

What is an Identity?
A stable logical entity
associated with a
series of different Values
over time

13

What is State?
The Value
an entity with a
specific Identity
has at a particular
point in time

14

How do we know if
something has State?
If a function is invoked with
the same arguments at
two different points in time and
returns different values...

...then it has state
15

The Problem
Unification of
Identity & Value
They are
not
the same
16

We need to separate Identity & Value
...add a level of indirection
Software Transactional Memory
Managed References

Message-Passing Concurrency
Actors/Active Objects

Dataflow Concurrency
Dataflow (Single-Assignment) Variables
17

Shared-State
Concurrency

18

Shared-State Concurrency
> Concurrent access to shared, mutable state.
> Protect mutable state with locks
> The
 Java

 C#

 C/C++

 Ruby

 Python

 etc.

 ...way

19

Shared-State Concurrency is
incredibly hard
> Inherentlyvery hard to use reliably
> Even the experts get it wrong

20

Roadmap:
Let’s look at three problem domains
1. Need for consensus and truly shared knowledge
Example: Banking

2. Coordination of independent tasks/processes
Example: Scheduling, Gaming

3. Workflow related dependent processes
Example: Business processes, MapReduce

21

...and for each of these...
1. Look at an implementation using

2. Compare with implementation using an
alternative paradigm

22

Roadmap:
Example: Banking



23

Problem 1:
Transfer funds
between bank accounts

24

Transfer funds

25

Account
public class Account {  
  private double balance;  
  public void withdraw(double amount) { 
    balance ‐= amount; 
  }  
  public void deposit(double amount) { 
    balance += amount; 
  }  
} 
> Not thread-safe 
26

Let’s make it thread-safe
public class Account {  
  private double balance;  
  public synchronized void withdraw(double amount) { 
    balance ‐= amount; 
  }  
  public synchronized void deposit(double amount) { 
    balance += amount; 
  }  
} 
>Thread-safe, right?  

27

It’s still broken
Not atomic

28

Let’s write an atomic transfer method
public class Account {
  ...
   public synchronized void transferTo(
     Account to, double amount) {
     this.withdraw(amount);  
     to.deposit(amount);
   }  
   ...
 }

> This will work right?
29

Let’s transfer funds
Account alice = ...  
Account bob = ...  
  
// in one thread  
alice.transferTo(bob, 10.0D);  
  
// in another thread  
bob.transferTo(alice, 3.0D); 

30

Might lead to
DEADLOCK
Darn, this is really hard!!!

31

We need to enforce lock ordering
> How?
> Java won’t help us
> Need to use code convention (names etc.)
> Requires knowledge about the internal state
and implementation of Account
> …runs counter to the principles of
encapsulation in OOP
> Opens up a Can of Worms

32

The problem with locks
Locks do not compose
Taking too few locks
Taking too many locks
Taking the wrong locks
Taking locks in the wrong order
Error recovery is hard

33

Java bet on the
wrong horse
But we’re not completely screwed
There are alternatives

34

We need better
and more high-level
abstractions

35

Alternative Paradigms
>Software Transactional Memory (STM)
>Message-Passing Concurrency (Actors)
>Dataflow Concurrency

36

Software Transactional
Memory (STM)

37

> See the memory (heap and stack) as a
transactional dataset
> Similar to a database
 begin

 commit

 abort/rollback

> Transactions are retried automatically upon
collision
> Rolls back the memory on abort

38

> Transactions can nest
> Transactions compose (yipee!!)
   atomic {   
     ..   
     atomic {    
       ..    
     }  
   }  

39

Restrictions
> All
operations in scope of a transaction:
 Need to be idempotent

 Can’t have side-effects

40

Case study:
Clojure

41

What is Clojure?
> Functionallanguage
> Runs on the JVM
> Only immutable data and datastructures
> Pragmatic Lisp
> Great Java interoperability
> Dynamic, but very fast

42

Clojure’s concurrency story
> STM (Refs)
 Synchronous Coordinated

> Atoms
 Synchronous Uncoordinated

> Agents
 Asynchronous Uncoordinated

> Vars
 Synchronous Thread Isolated

43

STM (Refs)
>A Ref holds a reference to an immutable value
> A Ref can only be changed in a transaction
> Updates are atomic and isolated (ACI)
> A transaction sees its own snapshot of the world
> Transactions are retried upon collision

44

Let’s get back to our banking problem

The STM way
Transfer funds

45

Create two accounts
;; alice’s account with balance 1000 USD
(def alice (ref 1000)) 

;; bob’s account with balance 1000 USD
(def bob (ref 1000)) 

46

Transfer 100 bucks
;; amount to transfer
(def amount 100)      

;; not valid
;; throws exception since 
;; no transaction is running
(ref‐set alice (‐ @alice amount)) 
(ref‐set bob (+ @bob amount))

47

Wrap in a transaction

;; update both accounts inside a transaction
(dosync 
  (ref‐set alice (‐ @alice amount))
  (ref‐set bob (+ @bob amount)))

48

Potential problems with STM
High contention (many transaction collisions) can lead to:
Potential bad performance and too high latency
Progress can not be guaranteed (e.g. live locking)
Fairness is not maintained
Implementation details hidden in black box

49

My (humble) opinion on STM
> Can never work fine in a language that don’t have
compiler enforced immutability
> E.g. never in Java (as of today)

> Shouldnot be used to “patch” Shared-State
Concurrency

> Still
a research topic how to do it in imperative
languages

50

Discussion: Problem 1
Need for consensus and truly shared knowledge
Bad fit
Great fit
Terrible fit
Terrible fit

51

Message-Passing
Concurrency

52

Actor Model of Concurrency
> Implements Message-Passing Concurrency
> Originates in a 1973 paper by Carl Hewitt
> Implemented in Erlang, Occam, Oz
> Encapsulates state and behavior
> Closer to the definition of OO than classes

53

> Share NOTHING
> Isolated lightweight processes
> Can easily create millions on a single workstation
> Communicates through messages
> Asynchronous and non-blocking

54

> No shared state
 … hence, nothing to synchronize.

> Each actor has a mailbox (message queue)

55

> Non-blocking send
> Blocking receive
> Messages are immutable
> Highly performant and scalable
 Similar to Staged Event Driven Achitecture style (SEDA)

56

> Easier to reason about
> Raised abstraction level
> Easier to avoid
 Race conditions

 Deadlocks

 Starvation

 Live locks

57

Fault-tolerant systems
> Link actors
> Supervisor hierarchies
 One-for-one

 All-for-one

> Ericsson’s Erlang success story
 9 nines availability (31 ms/year downtime)

58

Roadmap:
Example: Banking



59

Problem 2:
A game of ping pong

60

A game of ping pong

61

Ping Pong Table
public class PingPongTable {
  public void hit(String hitter) {
    System.out.println(hitter);
  }
}

62

Player
public class Player implements Runnable {
  private PingPongTable myTable; 
  private String myName;
  public Player(String name, 
                PingPongTable table) {
    myName = name;
    myTable = table;
  }

  ...
}
63

Player cont...
  ...
  public void run() {
    while (true) {
      synchronized(myTable) {
        try {
          myTable.hit(myName);
          myTable.notifyAll();
          myTable.wait();
        } catch (InterruptedException e) {}
      }
    }
  }
}
64

Run it
PingPongTable table = new PingPongTable();
Thread ping = 
    new Thread(new Player("Ping", table));
Thread pong = 
    new Thread(new Player("Pong", table));
ping.start(); 
pong.start(); 

65

Help: java.util.concurrent
> Great library
> Raises the abstraction level
> No more wait/notify & synchronized blocks
> Concurrent collections
> Executors, ParallelArray
> Simplifies concurrent code
> Use it, don’t roll your own

66

Actors
A game of ping pong

67

Define message

case object Ball

68

Player 1: Pong
 val pong = actor {
    loop { 
      receive {      // wait on message
        case Ball => // match on message Ball
          println("Pong")
          reply(Ball)
      }
    }
  }

69

Player 2: Ping
 val ping = actor {
    pong ! Ball // start the game
    loop { 
      receive {
        case Ball => 
          println("Ping")
          reply(Ball)
      }
    }
  }
70

Run it
...well, they are already up and running

71

Actor implementations for the JVM
> Killim(Java)
> Jetlang (Java)
> Actor’s Guild (Java)
> ActorFoundry (Java)
> Actorom (Java)
> FunctionalJava (Java)
> Akka Actor Kernel (Java/Scala)
> GParallelizer (Groovy)
> Fan Actors (Fan)

72

Coordination of interrelated tasks/processes

Bad fit (ok if java.util.concurrent is used)
STM
Won’t help
Great fit
Ok

73

The forgotten paradigm

74

> Declarative
> No observable non-determinism
> Data-driven – threads block until data is available
> On-demand, lazy
> No difference between:
> Concurrent and
> Sequential code

75

> No race-conditions
> Deterministic
> Simple and beautiful

76

> Dataflow (Single-Assignment) Variables
> Dataflow Streams (the tail is a dataflow variable)
> Implemented in Oz and Alice

77

Just three operations
> Create a dataflow variable
> Wait for the variable to be bound
> Bind the variable

78

Limitations
> Can’t have side-effects
 Exceptions

 IO (println, File, Socket etc.)

 Time

 etc.

 Not general-purpose

 Generally good for well-defined isolated modules

79

Oz-style dataflow concurrency for the JVM
> Created my own implementation (DSL)
> On top of Scala

80

API: Dataflow Variable
// Create dataflow variable  
val x, y, z = new DataFlowVariable[Int]  
  
// Access dataflow variable (Wait to be bound)  
z()  
  
// Bind dataflow variable  
x << 40  
  
// Lightweight thread  
thread { y << 2 }  
81

API: Dataflow Stream
Deterministic streams (not IO streams)

// Create dataflow stream  
val producer = new DataFlowStream[Int]  
  
// Append to stream  
producer <<< s  
  
// Read from stream  
producer()  

82

Roadmap:
Example: Banking



83

Problem 3:
Producer/Consumer

84

Producer/Consumer

85

Use java.util.concurrent
Fork/Join framework (ParallelArray etc.)
ExecutorService
Future
BlockingQueue

86

Producer/Consumer

87

Example: Dataflow Variables
// sequential version
x << 40 
y << 2
z << x() + y()  
println("z = " + z())  

88

Example: Dataflow Variables
// concurrent version: no difference
thread { x << 40 }  
thread { y << 2 }  
thread {  
  z << x() + y()  
  println("z = " + z())  
}

89

Dataflow Concurrency in Java

DataRush (commercial)
Flow-based Programming in Java (dead?)
FlowJava (academic and dead)

90

Workflow related dependent processes

Ok (if java.util.concurrent is used)
STM
Won’t help
Ok
Great fit

91

Wrap up
> Parallel programs is becoming increasingly important
> We need a simpler way of writing concurrent
programs
> “Java-style” concurrency is too hard
> There are alternatives worth exploring
 Message-Passing Concurrency

 Software Transactional Memory

 Dataflow Concurrency

 Each with their strengths and weaknesses

92

Jonas Bonér
Crisp AB
blog: http://jonasboner.com
work: http://crisp.se
code: http://github.com/jboner
twitter: jboner

93

stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf

More Related Content

Similar to stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf (20)

More from Hiroshi Ono (20)

stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf