Gael Fraiteur argues that multithreaded programming needs to be addressed at the right level of abstraction, with design patterns like Actor, Immutable, Freezable, Thread Affine, Reader-Writer-Synchronized. Design patterns form a language and serve as a model against which code can be expressed. Compilers must support design patterns to allow code to be deterministically validated against the model, and of course to generate the low-level instructions that would be otherwise written manually.
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
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
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
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)
32. @gfraiteur
Assign threading models
to types
1. Every class must be assigned a threading model.
2. Define aggregates with appropriate granularity.
1.
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.
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
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”
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
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“
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
Editor's Notes
Good morning! My name is Gael Fraiteur. If you think I have a weird accent and even think I am French, but actually I was grown in Belgium and have lived in Czech Republic for the last 12 years.I have been programming non-stop since age of 11, building my first useful program at 12 – it was still reported in use when I got married. My father has been involved with IT in most of his career and my grandfather was probably one of the first programmers in Belgium.(connect to the audience)My grandfather had a PhD in meteorology. He was involved in early weather prediction computing. It’s always fun to talk with him about these heroic times of computing. By far, the rarest resource was working memory (RAM). They had just a few kilobytes of it, and it has to contain the data and the program. Of course they wrote their code in assembly because the single very optimization was importance.Also, they were moving data between RAM and disk back and forth. Of course we’re still doing that when we need to work with dataset that exceed a few GBs. But even doing that was not enough to keep under the 4KB limit, so they also dynamically loaded and unloaded parts of the program – just to save a few hundred bytes. We’re still doing that today but this is transparent to the application programmer thanks to the concept of virtual memory. Virtual memory is an abstraction layer that hides implementation details. There are other abstraction layers: the operating system, the CLR, the programming languages, and the frameworks. All these layers ultimately allow us to write code at a high level of abstraction, without bothering of implementation details.So, there has been this amazing evolution in sixty years. Most of us here are the third generation of programmers. Our predecessors did a marvelous job. What are our today’s challenges and what will be our contribution? Twenty years from now, will our successors laugh at us, consider our current programming languages as mere evolutions of the assembly language, and most of our code as technical wiring that will then be done automatically by “the machine”? I hope so, I hope our generation will be able to make a difference.Today’s challenge is no longer scarce resources, but multithreading. I think this is the number-one problem that our generation needs to tackle. And I think we should get inspiration from our predecessors: how did they succeed with the memory management problem? What are the lessons we can apply today? In this talk, I will argue that we should once again raise the level of abstraction and, this time, we should investigate how programming languages and compilers could allow for a better use of design patterns – or threading models, in this case.Nine years ago, I started working on an open-source project named PostSharp. Essentially, PostSharp allows developers to write custom attributes that extend the language, because PostSharp post-processes the compiler’s output at build time. Most examples in this talk are written in PostSharp, but this talk is more conceptual than practical, so examples are not a big deal of it.
Three years ago, PostSharp outgrew my capacity to maintain it as a free open-source project and, out of necessity, became a commercial product. In an industry dominated by open source and big platform vendors, to make a living from development tools is extraordinarily difficult. We at PostSharp Technologies have been fortunate enough to succeed in this endeavor. We are grateful for the trust we receive from our customers – from the one-man shop to the largest corporations.This remark should also serve as a disclaimer that this talk shall undoubted be biased by my very source of revenues.However, my commitment to you in this talk is to share the vision which motivates us day after day. This vision is much larger than our product itself, and you can implement it with other tools, perhaps less appropriate – and, hopefully we will be able to spark an idea that will influence the design of future language and compilers.
UNIVAC1 control station
Mercury delay line memory of UNIVAC 1 (1951) approx. 13 KBhttp://univac1.0catch.com/#b218 channels, each 10 words of 12 6-bit characters http://en.wikipedia.org/wiki/File:Mercury_memory.jpg
Programming for the UNIVAC FAC-TRONIC system, 1935 by Remington Rand inchttp://bitsavers.informatik.uni-stuttgart.de/pdf/univac/univac1/UNIVAC_Programming_Jan53.pdf
http://www.thefreewallpapers.com/wp-content/uploads/2011/06/Tree-in-nature.jpgNow that even mobile phones have multiple cores, it is no longer original to repeat that the free lunch is over and that software developers must embrace multithreaded programming. Although this is much more complex than single-threaded programming, there’s little chance that software developers are going to get smarter – I mean that our cognitive abilities are not likely to increase so much. Investments in training and other skill improvement are necessary but are not going to bring the order-of-magnitude improvement we need to face tomorrow’s growing challenge. Instead, I believe we should focus breaking down complexity – that is, to it easier to write good software.The software industry faced a similar challenge sixty years ago with memory management, and we should look at how our predecessors tackled the problem. What they did is to define a memory model that was close to the way we humans think, and to build compiler to translate code expressed against this model into code that can be executed by the machine. That is, the first programming languages addressed complexity by raising the abstraction level. We need to repeat this success with multithreading. That is, we need to be able to build code against threading models (or threading patterns), and the compiler or runtime environment should be smart enough to perform deterministic validation of our code.Moreover, I think we need compilers that allow us to define our own models and design patterns. Not only for multithreading, but for any other concern. In an ideal world, humans should tell the machines what needs to be done and not how to do it. In an ideal world, source code should not be significantly more difficult or larger than the description of a solution in natural language.With PostSharp, we are proud to contribute to this v