Multithreading Design Patterns
•Als PPTX, PDF herunterladen•
12 gefällt mir•20,834 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Multithreading Design Patterns
Ähnlich wie Multithreading Design Patterns (20)
Mehr von PostSharp Technologies
Mehr von PostSharp Technologies (8)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Multithreading Design Patterns
- 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
- 6. @gfraiteur hardware was fun but quite simple to use
- 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.
- 44. @gfraiteur Actor Model Bound to a single thread (at a time)
- 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”
- 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
- 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
Hinweis der Redaktion
- 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://en.wikipedia.org/wiki/File:FortranCardPROJ039.agr.jpg
- LISP 1.5 Programmer’s Manual
- http://www.ibiblio.org/pub/languages/fortran/ch1-1.html20x less statements than assembly
- http://blog.superfeedr.com/ruby/open/ruby-fibers-may-confuse/
- 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