0
State You’re Doing it Wrong:
Alternative Concurrency
Paradigms For the JVM
Jonas Bonér
Crisp AB
blog: http://jonasboner.co...
Agenda
> An Emergent Crisis
> State: Identity vs Value
> Shared-State Concurrency
> Software Transactional Memory (STM)
> ...
Moore’s Law
> Coined in the 1965 paper by Gordon E. Moore
> The number of transistors is doubling every
  18 months
> Proc...
Not anymore

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




                                ...
Conclusion
> This is an emergent crisis
> Multi-processors are here to stay
> We need to learn to take advantage of that
>...
State
        7
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
   ...
What is an Identity?
  A stable logical entity
    associated with a
series of different Values
        over time


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

                    ...
How do we know if
    something has State?
  If a function is invoked with
     the same arguments at
two different points...
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

Mes...
Shared-State
Concurrency


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

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




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

2. Co...
...and for each of these...
1. Look at an implementation using
   Shared-State Concurrency

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

2. Co...
Problem 1:
    Transfer funds
between bank accounts


                        24
Shared-State Concurrency
        Transfer funds
    between bank accounts


                            25
Account
public
class
Account
{




private
double
balance;




public
void
withdraw(double
amount)
{





balance
‐=
amoun...
Let’s make it thread-safe
public
class
Account
{




private
double
balance;




public
synchronized
void
withdraw(double
...
It’s still broken
     Not atomic



                  28
Let’s write an atomic transfer method
 public
class
Account
{
 

...



public
synchronized
void
transferTo(





Account
...
Let’s transfer funds
Account
alice
=
...


Account
bob
=
...





//
in
one
thread


alice.transferTo(bob,
10.0D);





//...
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 knowled...
The problem with locks
Locks do not compose
Taking too few locks
Taking too many locks
Taking the wrong locks
Taking locks...
Java bet on the
  wrong horse
But we’re not completely screwed
     There are alternatives


                             ...
We need better
and more high-level
   abstractions


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



...
Software Transactional
    Memory (STM)


                     37
Software Transactional Memory
> See   the memory (heap and stack) as a
  transactional dataset
> Similar to a database
  ...
Software Transactional Memory
> Transactions can nest
> Transactions compose (yipee!!)



atomic
{








..








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

  Can’t have side-effects




    ...
Case study:
Clojure

              41
What is Clojure?
> Functionallanguage
> Runs on the JVM
> Only immutable data and datastructures
> Pragmatic Lisp
> Great ...
Clojure’s concurrency story
> STM  (Refs)
   Synchronous Coordinated

> Atoms
   Synchronous Uncoordinated

> Agents
  ...
STM (Refs)
>A  Ref holds a reference to an immutable value
> A Ref can only be changed in a transaction
> Updates are atom...
Let’s get back to our banking problem




    The STM way
      Transfer funds
  between bank accounts

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


;;
bob’s
account
with
balance
1000
U...
Transfer 100 bucks
;;
amount
to
transfer
(def
amount
100)







;;
not
valid
;;
throws
exception
since

;;
no
transaction...
Wrap in a transaction

;;
update
both
accounts
inside
a
transaction
(dosync



(ref‐set
alice
(‐
@alice
amount))


(ref‐se...
Potential problems with STM
High contention (many transaction collisions) can lead to:
   Potential bad performance and to...
My (humble) opinion on STM
> Can  never work fine in a language that don’t have
 compiler enforced immutability
 > E.g. ne...
Discussion: Problem 1
Need for consensus and truly shared knowledge
Shared-State Concurrency
  Bad fit
Software Transactio...
Message-Passing
  Concurrency


                  52
Actor Model of Concurrency
> Implements   Message-Passing Concurrency
> Originates in a 1973 paper by Carl Hewitt
> Implem...
Actor Model of Concurrency
> Share  NOTHING
> Isolated lightweight processes
 >   Can easily create millions on a single w...
Actor Model of Concurrency
> No shared state
   … hence, nothing to synchronize.

> Each actor has a mailbox (message que...
Actor Model of Concurrency
> Non-blocking    send
> Blocking receive
> Messages are immutable
> Highly performant and scal...
Actor Model of Concurrency
> Easier   to reason about
> Raised abstraction level
> Easier to avoid
   Race conditions

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

   All-for-one

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

2. Co...
Problem 2:
A game of ping pong



                      60
Shared-State Concurrency
     A game of ping pong



                           61
Ping Pong Table
public
class
PingPongTable
{


public
void
hit(String
hitter)
{




System.out.println(hitter);


}
}




...
Player
 public
class
Player
implements
Runnable
{
 

private
PingPongTable
myTable;

 

private
String
myName;
 

public
P...
Player cont...


...


public
void
run()
{




while
(true)
{






synchronized(myTable)
{








try
{










myTabl...
Run it
PingPongTable
table
=
new
PingPongTable();
Thread
ping
=





new
Thread(new
Player("Ping",
table));
Thread
pong
=
...
Help: java.util.concurrent
> Great  library
> Raises the abstraction level
  > No more wait/notify & synchronized blocks
 ...
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
me...
Player 2: Ping

val
ping
=
actor
{




pong
!
Ball
//
start
the
game




loop
{







receive
{








case
Ball
=>




...
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 (...
Discussion: Problem 2
Coordination of interrelated tasks/processes

Shared-State Concurrency
  Bad fit (ok if java.util.co...
Dataflow Concurrency
  The forgotten paradigm




                           74
Dataflow Concurrency
> Declarative
> No  observable non-determinism
> Data-driven – threads block until data is available
...
Dataflow Concurrency
> No race-conditions
> Deterministic
> Simple and beautiful




                         76
Dataflow Concurrency
> Dataflow (Single-Assignment) Variables
> Dataflow Streams (the tail is a dataflow variable)
> Imple...
Just three operations
> Create  a dataflow variable
> Wait for the variable to be bound
> Bind the variable




          ...
Limitations
> Can’t  have side-effects
   Exceptions

   IO (println, File, Socket etc.)

   Time

   etc.

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




               ...
API: Dataflow Variable
//
Create
dataflow
variable


val
x,
y,
z
=
new
DataFlowVariable[Int]





//
Access
dataflow
varia...
API: Dataflow Stream
Deterministic streams (not IO streams)

//
Create
dataflow
stream


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

2. Co...
Problem 3:
Producer/Consumer



                    84
Shared-State Concurrency
     Producer/Consumer



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




               ...
Dataflow Concurrency
   Producer/Consumer



                       87
Example: Dataflow Variables
//
sequential
version
val
x,
y,
z
=
new
DataFlowVariable[Int]


x
<<
40

y
<<
2
z
<<
x()
+
y()...
Example: Dataflow Variables
//
concurrent
version:
no
difference
val
x,
y,
z
=
new
DataFlowVariable[Int]


thread
{
x
<<
4...
Dataflow Concurrency in Java

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


...
Discussion: Problem 3
Workflow related dependent processes

Shared-State Concurrency
  Ok (if java.util.concurrent is used...
Wrap up
> Parallel programs is becoming increasingly important
> We need a simpler way of writing concurrent
  programs
> ...
Jonas Bonér
Crisp AB
blog: http://jonasboner.com
work: http://crisp.se
code: http://github.com/jboner
twitter: jboner

   ...
Upcoming SlideShare
Loading in...5
×

stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf

722

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
722
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf"

  1. 1. 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
  2. 2. Agenda > An Emergent Crisis > State: Identity vs Value > Shared-State Concurrency > Software Transactional Memory (STM) > Message-Passing Concurrency (Actors) > Dataflow Concurrency > Wrap up 2
  3. 3. 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
  4. 4. Not anymore 4
  5. 5. The free lunch is over > Theend of Moore’s Law > We can’t squeeze more out of one CPU 5
  6. 6. 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
  7. 7. State 7
  8. 8. The devil is in the state 8
  9. 9. Wrong, let me rephrase 9
  10. 10. The devil is in the mutable state 10
  11. 11. Definitions & Philosophy 11
  12. 12. What is a Value? A Value is something that does not change Discussion based on http://clojure.org/state by Rich Hickey 12
  13. 13. What is an Identity? A stable logical entity associated with a series of different Values over time 13
  14. 14. What is State? The Value an entity with a specific Identity has at a particular point in time 14
  15. 15. 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
  16. 16. The Problem Unification of Identity & Value They are not the same 16
  17. 17. 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
  18. 18. Shared-State Concurrency 18
  19. 19. Shared-State Concurrency > Concurrent access to shared, mutable state. > Protect mutable state with locks > The  Java  C#  C/C++  Ruby  Python  etc.  ...way 19
  20. 20. Shared-State Concurrency is incredibly hard > Inherentlyvery hard to use reliably > Even the experts get it wrong 20
  21. 21. 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
  22. 22. ...and for each of these... 1. Look at an implementation using Shared-State Concurrency 2. Compare with implementation using an alternative paradigm 22
  23. 23. 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 23
  24. 24. Problem 1: Transfer funds between bank accounts 24
  25. 25. Shared-State Concurrency Transfer funds between bank accounts 25
  26. 26. 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
  27. 27. 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
  28. 28. It’s still broken Not atomic 28
  29. 29. 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
  30. 30. 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
  31. 31. Might lead to DEADLOCK Darn, this is really hard!!! 31
  32. 32. 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
  33. 33. 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
  34. 34. Java bet on the wrong horse But we’re not completely screwed There are alternatives 34
  35. 35. We need better and more high-level abstractions 35
  36. 36. Alternative Paradigms >Software Transactional Memory (STM) >Message-Passing Concurrency (Actors) >Dataflow Concurrency 36
  37. 37. Software Transactional Memory (STM) 37
  38. 38. Software Transactional Memory > 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
  39. 39. Software Transactional Memory > Transactions can nest > Transactions compose (yipee!!) 


atomic
{


 




..


 




atomic
{



 






..



 




}

 


}

 39
  40. 40. Restrictions > All operations in scope of a transaction:  Need to be idempotent  Can’t have side-effects 40
  41. 41. Case study: Clojure 41
  42. 42. What is Clojure? > Functionallanguage > Runs on the JVM > Only immutable data and datastructures > Pragmatic Lisp > Great Java interoperability > Dynamic, but very fast 42
  43. 43. Clojure’s concurrency story > STM (Refs)  Synchronous Coordinated > Atoms  Synchronous Uncoordinated > Agents  Asynchronous Uncoordinated > Vars  Synchronous Thread Isolated 43
  44. 44. 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
  45. 45. Let’s get back to our banking problem The STM way Transfer funds between bank accounts 45
  46. 46. 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
  47. 47. 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
  48. 48. Wrap in a transaction ;;
update
both
accounts
inside
a
transaction (dosync
 

(ref‐set
alice
(‐
@alice
amount)) 

(ref‐set
bob
(+
@bob
amount))) 48
  49. 49. 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
  50. 50. 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
  51. 51. Discussion: Problem 1 Need for consensus and truly shared knowledge Shared-State Concurrency Bad fit Software Transactional Memory Great fit Message-Passing Concurrency Terrible fit Dataflow Concurrency Terrible fit 51
  52. 52. Message-Passing Concurrency 52
  53. 53. 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
  54. 54. Actor Model of Concurrency > Share NOTHING > Isolated lightweight processes > Can easily create millions on a single workstation > Communicates through messages > Asynchronous and non-blocking 54
  55. 55. Actor Model of Concurrency > No shared state  … hence, nothing to synchronize. > Each actor has a mailbox (message queue) 55
  56. 56. Actor Model of Concurrency > Non-blocking send > Blocking receive > Messages are immutable > Highly performant and scalable  Similar to Staged Event Driven Achitecture style (SEDA) 56
  57. 57. Actor Model of Concurrency > Easier to reason about > Raised abstraction level > Easier to avoid  Race conditions  Deadlocks  Starvation  Live locks 57
  58. 58. 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
  59. 59. 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 59
  60. 60. Problem 2: A game of ping pong 60
  61. 61. Shared-State Concurrency A game of ping pong 61
  62. 62. Ping Pong Table public
class
PingPongTable
{ 

public
void
hit(String
hitter)
{ 



System.out.println(hitter); 

} } 62
  63. 63. Player public
class
Player
implements
Runnable
{ 

private
PingPongTable
myTable;
 

private
String
myName; 

public
Player(String
name,
 















PingPongTable
table)
{ 



myName
=
name; 



myTable
=
table; 

} 

... } 63
  64. 64. Player cont... 

... 

public
void
run()
{ 



while
(true)
{ 





synchronized(myTable)
{ 







try
{ 









myTable.hit(myName); 









myTable.notifyAll(); 









myTable.wait(); 







}
catch
(InterruptedException
e)
{} 





} 



} 

} } 64
  65. 65. 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
  66. 66. 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
  67. 67. Actors A game of ping pong 67
  68. 68. Define message case
object
Ball 68
  69. 69. Player 1: Pong 
val
pong
=
actor
{ 



loop
{
 





receive
{





//
wait
on
message 







case
Ball
=>
//
match
on
message
Ball 









println("Pong") 









reply(Ball) 





} 



} 

} 69
  70. 70. Player 2: Ping 
val
ping
=
actor
{ 



pong
!
Ball
//
start
the
game 



loop
{
 





receive
{ 







case
Ball
=>
 









println("Ping") 









reply(Ball) 





} 



} 

} 70
  71. 71. Run it ...well, they are already up and running 71
  72. 72. 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
  73. 73. Discussion: Problem 2 Coordination of interrelated tasks/processes Shared-State Concurrency Bad fit (ok if java.util.concurrent is used) STM Won’t help Message-Passing Concurrency Great fit Dataflow Concurrency Ok 73
  74. 74. Dataflow Concurrency The forgotten paradigm 74
  75. 75. Dataflow Concurrency > Declarative > No observable non-determinism > Data-driven – threads block until data is available > On-demand, lazy > No difference between: > Concurrent and > Sequential code 75
  76. 76. Dataflow Concurrency > No race-conditions > Deterministic > Simple and beautiful 76
  77. 77. Dataflow Concurrency > Dataflow (Single-Assignment) Variables > Dataflow Streams (the tail is a dataflow variable) > Implemented in Oz and Alice 77
  78. 78. Just three operations > Create a dataflow variable > Wait for the variable to be bound > Bind the variable 78
  79. 79. 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
  80. 80. Oz-style dataflow concurrency for the JVM > Created my own implementation (DSL) > On top of Scala 80
  81. 81. 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
  82. 82. 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
  83. 83. 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 83
  84. 84. Problem 3: Producer/Consumer 84
  85. 85. Shared-State Concurrency Producer/Consumer 85
  86. 86. Use java.util.concurrent Fork/Join framework (ParallelArray etc.) ExecutorService Future BlockingQueue 86
  87. 87. Dataflow Concurrency Producer/Consumer 87
  88. 88. Example: Dataflow Variables //
sequential
version val
x,
y,
z
=
new
DataFlowVariable[Int]

 x
<<
40
 y
<<
2 z
<<
x()
+
y()

 println("z
=
"
+
z())

 88
  89. 89. Example: Dataflow Variables //
concurrent
version:
no
difference val
x,
y,
z
=
new
DataFlowVariable[Int]

 thread
{
x
<<
40
}

 thread
{
y
<<
2
}

 thread
{

 

z
<<
x()
+
y()

 

println("z
=
"
+
z())

 } 89
  90. 90. Dataflow Concurrency in Java DataRush (commercial) Flow-based Programming in Java (dead?) FlowJava (academic and dead) 90
  91. 91. Discussion: Problem 3 Workflow related dependent processes Shared-State Concurrency Ok (if java.util.concurrent is used) STM Won’t help Message-Passing Concurrency Ok Dataflow Concurrency Great fit 91
  92. 92. 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
  93. 93. Jonas Bonér Crisp AB blog: http://jonasboner.com work: http://crisp.se code: http://github.com/jboner twitter: jboner 93
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×