1. Actor Model
Programming the future, with knowledge from the past

4. Concurrency.
Why shouldwe
care?

5. 1973–2017

9. What the hell are you
talking about?

10. Concurrency
...time to embrace it.

11. Why is it so hard?

12. 2
State

13. The devil is in
the state

14. The devil is in
the mutablestate

15. Definitions
&
Philosophy

16. What is a
Value?

17. What is a
Value?
A value is somethingthat
does not change

18. What is an
Identity?

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

20. What is
State?

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

22. How do we know if
something has
State?

23. 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...

24. The problems
with Shared
State
Concurrency

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

26. Example of
Shared-State Concurrency
Transfer funds
between bank
accounts

27. Account
public class Account {
private int balance;
public void withdraw(int amount){
if(balance < amount) throw;
balance ‐= amount;
}
public void deposit(int amount){
balance += amount;
}
}

28. Account
public class Account {
private int balance;
public void withdraw(int amount){
if(balance < amount) throw;
balance ‐= amount;
}
public void deposit(int amount){
balance += amount;
}
}
Not thread-safe 

29. Let’s make it thread-safe
public class Account {
private int balance;
public synchronized void withdraw(int amount) {
if(balance < amount) throw;
balance ‐= amount;
}
public synchronized void deposit(int amount) {
balance += amount;
}
}
Thread-safe right?

30. It’s still
brokenTransfers are not
atomic

31. Let’s write an
atomic transfer method
public class Account {
...
public synchronized void
transfer(Account to, int amount) {
this.withdraw(amount);
to.deposit(amount);
}
...
}
This will work right?

32. Let’s transfer funds
Account alice = ...
Account bob = ...
alice.transferTo(bob, 10.0D);
bob.transferTo(alice, 3.0D);

33. Let’s transfer funds
Account alice = ...
Account bob = ...
alice.transferTo(bob, 10.0D);
bob.transferTo(alice, 3.0D);

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

35. Weneed to enforce lock
ordering
>How?
>Java or C# won’t help us
>Need to use code convention (names
etc.)
>Requires knowledge about the internal
state and implementation of Account
>…runscounter to the principles
of encapsulation in OOP

36. You have a lock problem

37. It’s just
too hard

38. MULTITHREA DING
THEORY
PRACTICE

39. CHECK OUT
MYMULTITHREADEDCODE

40. HOW MA NY THREA DS
DOESITTAKETOCHANGEALIGHTBULB?

41. Infrasture!

42. Enterprise CRUDApp

43. Enterprise CRUDApp

44. Enterprise CRUDApp

45. Obvious Solution: Sharding

47. Brittle

49. What is the actor model?

50. MESSAGE
ALL THE THINGS

51. 1973

53. Everything is an
actor.

54. Okay.. so what is an
actor?

55. 3 Core Abilities
1. Send messages
2. Create other actors
3. Change behavior

56. Messages

57. Messages
→ Must be immutable
→ Processed serially
Messages are values

59. async by
default

60. Sending aMessage
myActorRef.Tell("this is my message");

61. Create Other
Actors

62. Actors never come
alone!

63. Actor Hierarchy

64. Location
Transparency

66. Actors Live at Unique Addresses

69. Which
means...

72. What is
Akka.NET?

75. This Is AnAkka.NET Actor
public class FooActor : UntypedActor
{
public FooActor()
{
// message handling code goes here...
}
}

76. These Are Messages
// just POCOs
public class
public class
Hello {}
NewOrder {
(string name)public NewOrder
{
Username
UserId =
= name;
Guid.NewGuid ();
}
Guid UserId { get; private set;}public
public string Username {get; private set;}
}

78. Without
Rewriting Your
Code

79. Money transfer
Actor style

80. Transfer
Manager

81. Transfer
Manager
Transfer 500
from A to B

82. //immutable message for withdraw:
public class TransferRequest
{
public string TransactionID;
public decimal Amount;
public string From;
public string To;
}
//the account actor
public class TransferManager : TypedActor, IHandle<Withdraw>
{
public void Handle(TransferRequest e)
{
...
}
}

83. Transfer
Manager
A
Withdraw 500

84. //immutable message for withdraw:
public class TransferRequest
{
public string TransactionID;
public decimal Amount;
public string From;
public string To;
}
//the account actor
public class TransferManager : TypedActor, IHandle<Withdraw>
{
public void Handle(TransferRequest e)
{
var fromAddress = "akka://my-sys/accounts/" + e.From;
Context.ActorSelection(fromAddress).Tell(new Withdraw(e.Amount));
}
}

85. Transfer
Manager
A
Withdraw 500

86. public class WithdrawRequest
{
public string TransactionID;
public decimal Amount;
}
//the account actor
public class BankAccount : TypedActor, IHandle<Withdraw>
{
private decimal _balance;
public void Handle(WithdrawRequest e)
{
if (_balance < e.Amount)
{
Sender.Tell(new WithdrawFailure(e.TransactionID));
return;
}
_balance -= e.Amount;
Sender.Tell(new WithdrawSuccess(e.TransactionID));
}
}

87. Transfer
Manager
A
B
Deposit 500

88. public class DepositRequest
{
public string TransactionID;
public decimal Amount;
}
//the account actor
public class BankAccount : TypedActor, IHandle<Withdraw>
{
private decimal _balance;
private decimal _maxAmount;
public void Handle(DepositRequest e)
{
if (_maxAmount < e.Amount)
{
Sender.Tell(new DepositFailure(e.TransactionID));
return;
}
_balance += e.Amount;
Sender.Tell(new DepositSuccess(e.TransactionID));
}
}

89. Transfer
Manager
A
B

90. //immutable message for withdraw:
public class TransferRequest
{
public string TransactionID;
public decimal Amount;
public string From;
public string To;
}
//the account actor
public class TransferManager : TypedActor, IHandle<Withdraw>
{
public void Handle(TransferRequest e)
{
Context.ActorSelection(transfer.From).Tell(new Withdraw(e.Amount));
Context.ActorSelection(transfer.To).Tell(new Deposit(e.Amount));
Sender.Tell(new TransferSuccess(e.TransactionID));
}
}

91. Transfer
Manager
A
B
Success

92. Change
Behavior

93. Actors
never come alone

94. Actors
have managers

95. Managed
References:a ?
:b ?
:c 42
:d ?
:e 6
• Typical OO: direct access to mutable
objects
foo
• Managed Reference: separates Identity &
Value
:a "fred"
:b "ethel"
:c 42
:d 17
:e 6
foo
@foo

96. How can this
be fast?
State Locality

98. Enterprise CRUD App

100. Let is crash!
An actor to monitor actors

101. Supervisor hierarchies
OneForOne
Wednesday, December 30,
2009

102. Supervisor hierarchies
AllForOne
Wednesday, December 30,
2009

103. THANK YOU!
Email: pj@craftify.nl
Twitter:
@pjvds