1.
@gfraiteur
Surmounting complexity by raising abstraction
Multithreading Design Patterns
Gaël Fraiteur
PostSharp Technologies
Founder & Principal Engineer

2.
@gfraiteur
Hello!
My name is GAEL.
No, I don’t think
my accent is funny.
my twitter

3.
@gfraiteur
My commitment to you:
to seed a vision, not to sell a tool.

4.
@gfraiteur
The vision:
Code at the right level of abstraction,
with compiler-supported design patterns

5.
@gfraiteur
back in
1951

6.
@gfraiteur
hardware was fun
but quite simple to use

7.
@gfraiteur
Univac Assembly Language

8.
@gfraiteur
FORTRAN (1955)
• 1955 - FORTRAN I
• Global Variables
• Arrays
• 1958 - FORTRAN II
• Procedural Programming
(no recursion)
• Modules

9.
@gfraiteur
COBOL (1959)
• Data Structures

10.
@gfraiteur
LISP (1959)
• Variable Scopes (Stack)
• Garbage Collection

11.
@gfraiteur
The new invention caught quickly, no wonder, programs
computing nuclear power reactor parameters took now
HOURS INSTEAD OF WEEKS
to write, and required much
LESS PROGRAMMING SKILL

12.
@gfraiteur
1. The Memory Management Revolution
2. Models and Patterns
3. Defining Threading Models
4. Designing with Threading Models
5. A Few Threading Models
6. Q&A
7. Summary
Section

13.
@gfraiteur
How do programming languages
increase productivity?

14.
@gfraiteur
What you
may think
the compiler
does for you.
Code Validation
Instruction Generation

15.
@gfraiteur
Compilers translate code
FROM HIGH
TO LOW ABSTRACTION language

16.
@gfraiteur
Languages let us express
ourselves against a model
Thing Concept Word
Model Language
∞ 1
World
abstracted into expressed with
∞ ∞
1 1
∞
1
1 1
abstracted into expressed with

17.
@gfraiteur
Good Models are Easy
• Allow for succinct expression of intent (semantics), with less
focus on implementation details
• less work
• fewer things to think about
• Allow for extensive validation of source code against the model
• early detection of errors
• Allow for better locality and separation of concerns
• “everything is related to everything” no more
• Are deterministic
• no random error

18.
@gfraiteur
Good Models are Friendly
• to human mind structure
• cope with limited human cognitive abilities
• to social organization
• cope with skillset differences, division of labor,
time dimension, changes in requirements

19.
@gfraiteur
The Classic Programming Model
Quality Realization
Succinct semantics • Concept of subroutine
• Unified concept of variable
(global, local, parameters, fields)
Validation • Syntactic (spelling)
• Semantic (type analysis)
• Advanced (data flow analysis)
Locality • Information hiding (member visibility)
• Modularity
Determinism • Total (uninterrupted single-threaded program)

20.
@gfraiteur
1. The Memory Management Revolution
2. Models and Patterns
3.Defining Threading Models
4. Designing with Threading Models
5. A Few Threading Models
6. Q&A
7. Summary
Section

21.
@gfraiteur
Why we need threading models
• Multithreading is way too hard – today
• Too many things to think about
• Too many side effects
• Random data races
• Your colleagues won’t get smarter
• Increased demand – end of free lunch

22.
@gfraiteur

23.
@gfraiteur
The Root of All Evil
Access to Shared Mutable State
• Memory ordering
• Atomicity / transactions
• Typical damage: data races
• Corruption of data structures
• Invalid states

24.
@gfraiteur
Locks alone are
not the solution

25.
@gfraiteur

26.
@gfraiteur
Locks alone are
not the solution
• Easy to forget
• Difficult to test
• Deadlocks

27.
@gfraiteur
"Problems cannot be solved by
the same level of thinking that
created them."
(and you’re not a man if you haven’t cited Albert Einstein)

28.
@gfraiteur
Threading Models
Reader-Writer
Sync’ed
Pessimistic
Transactions
Lock-Based
Lock-Free
Optimistic
Transactions
Transactional
Avoid Mutable State
Thread Exclusive
Immutable
Actor
Avoid Shared Mutable State
Avoid Shared State

29.
@gfraiteur
• Named solution
• Best practice
• Documented
• Abstraction
• Automation
• Validation
• Determinism
Threading Models are…
Models Design Patterns

30.
@gfraiteur
1. The Memory Management Revolution
2. Models and Patterns
3. Defining Threading Models
4.Designing with Threading Models
5. A Few Threading Models
6. Q&A
7. Summary
Section

31.
@gfraiteur
Golden rule: all shared state must be thread-safe.

32.
@gfraiteur
Assign threading models
to types
1. Every class must be assigned a threading model.
2. Define aggregates with appropriate granularity.
1.

33.
@gfraiteur
Product
Invoice
Party
Store
Invoice InvoiceLine
Product
-lines
1
-invoice
*
-product *
1
Party
-invoices1
-customer*
ProductPart-parts
1
-product
*
Address
-addresses
1*
StockItem
Store
-items 1
-store *
*
-part1
reader-writer-
synchronized
reader-writer-
synchronizedreader-writer-
synchronized
actor

34.
@gfraiteur
Ensure only thread-safe
types are shared
1. Arguments of cross-thread methods
2. All static fields must be read-only
and of thread-safe type.
2.

35.
@gfraiteur
1. The Memory Management Revolution
2. Models and Patterns
3. Defining Threading Models
4. Designing with Threading Models
5. A Few Threading Models
6. Q&A
7. Summary
Section

36.
@gfraiteur
Immutable Pattern
Never changed after creation.
Make a copy if you want to modify it.
Issue: multi-step object
initialization (e.g. deserialization)

37.
@gfraiteur
Freezable Pattern
1. Implement interface IFreezable
Freeze() must propagate to
children objects.
2. Before any non-const method, throw exception if
object is frozen.
3. Call the Freeze method after any initialization.

38.
@gfraiteur
Thread Exclusive
Promises never to be involved
with multithreading. Ever.

39.
@gfraiteur
Thread Exclusivity Strategies
• Exclusivity Policies:
• Thread Affinity (e.g. GUI objects)
• Instance-Level Exclusivity (e.g. most .NET objects)
• Type-Level Exclusivity
• Concurrency Behavior:
• Fail with exception
• Wait with a lock

40.
@gfraiteur
Implementing
Thread Affine Objects
• Remember current thread in constructor
• Verify current thread in any public method
• Prevent field access from outside current instance
• Only private/protected fields
• Only accessed in “this.field”

41.
@gfraiteur
Implementing Thread Excluse
Objects
• Acquire lock before any public method
• Wait/throw if it cannot be acquired
• Prevent field access from outside current instance
• Only private/protected fields
• Only accessed in “this.field”
• Note: “Throw” behavior is non-deterministic

42.
@gfraiteur
Stricter coding constraints increase code verifiability.

43.
@gfraiteur
Lab:
Checking Thread Exclusivity

44.
@gfraiteur
Actor Model
Bound to a single thread
(at a time)

45.
@gfraiteur
Message
Queue
Private
Mutable
State
Single
Worker
Actors:
No Mutable
Shared State

46.
@gfraiteur
Composing Actors

47.
@gfraiteur
Actor Sequence Diagram
Object1 Object2 Object3
Request1 Request2
Response1
Response2
Wait in
message
queue

48.
@gfraiteur
• with compiler support:
• Erlang,
• F# Mailbox
• PostSharp
• without compiler
support:
• NAct
• ActorFX
Actor implementations

49.
@gfraiteur
Verifying the Actor Model
• Public methods will be made async
• Parameters and return values
of public methods must be thread-safe
• Methods with return value must be async
• Prevent field access from outside current instance
• Only private/protected fields
• Only accessed in “this.field”

50.
@gfraiteur
Lab: Implementing Actors

51.
@gfraiteur
• Performance
• Theoretical Latency: min 20 ns
(L3 double-trip)
• Practical throughput (ring
buffer): max 6 MT/s per core
• Difficult to write
without proper
compiler support
• Reentrance issues with
waiting points (await)
• Race free (no shared
mutable state)
• Lock free (no waiting,
no deadlock)
• Scales across processes,
machines
Actors
Benefits Limitations

52.
@gfraiteur
Reader-Writer Synchronized
Everybody can read unless someone writes.

53.
@gfraiteur
Reader-Writer Synchronized
• 1 lock per [group of] objects
• e.g. invoice and invoice lines share the same lock
• Most public methods require locks:
Method Required Lock Level
Reads 1 piece of state None
Reads 2 pieces of state Read
Writes 1 piece of state Write
Reads large amount of state,
then writes state
Upgradeable Read, then
Write

54.
@gfraiteur
Lab: Implementing RWS

55.
@gfraiteur
Transactions
• Isolate shared state into thread-specific storage
• Commit/Rollback semantics
• Platform ensures ACID properties:
• Atomicity, Consistency, Isolation, (Durability)
• Type of concurrency policies
• Pessimistic (lock-based: several “isolation levels”
available)
• Optimistic (lock-free, retry-based)
As far as I'm concerned, I prefer silent vice
to ostentatious virtue. Albert Einstein“

56.
@gfraiteur
Q&A
Gael Fraiteur
gael@postsharp.net
@gfraiteur

57.
@gfraiteur
Summary
• Repeat the memory management
success with the multicore issue.
• Models decrease complexity to
a cognitively bearable level.
• We need compilers that allow
us to use our own models
and patterns.
BETTER SOFTWARE THROUGH SIMPLER CODE