1 / 22

Outline

Modern Concurrency Abstractions for C# by Nick Benton, Luca Cardelli & C´EDRIC FOURNET Microsoft Research. Outline. Introduction Polyphonic C# overview Specification Programming in Polyphonic C# Related work Future work Conclusion. Introduction. How is concurrency implemented ?

Download Presentation

Outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Modern Concurrency Abstractions for C#byNick Benton, Luca Cardelli & C´EDRIC FOURNETMicrosoft Research

  2. Outline • Introduction • Polyphonic C# overview • Specification • Programming in Polyphonic C# • Related work • Future work • Conclusion

  3. Introduction • How is concurrency implemented ? • Language feature • Libraries • Provides features like – memory management & exceptions • Advantages of having them as language features • Produce better code • Warn programmers of potential & actual problems

  4. They made concurrency as a language feature • Monitors - more asynchronous • Shift in focus – shared memory to event- or message-oriented concurrency • Programming constructs handling asynchronous communication • Polyphonic C#

  5. Polyphonic C# Overview • Extension to C# - new asynchronous concurrency constructs based on join calculus • New constructs – • Asynchronous methods • Chords • Asynchronous methods – • guaranteed to complete essentially immediately • Never returns a result • async keyword is used

  6. Chord – consists of a header and a body • Header - set of method declarations • Body is only executed once all the methods in the header have been called • Method calls are implicitly queued up until/unless there is a matching chord • If buff is instance of Buffer then call to buff.Get() has two possibilities • If there has previously been an unmatched call to buff .Put(s) • If there are no previous unmatched calls to buff .Put(s)

  7. Conversely - call to the asynchronous method buff .Put(s) has two possibilities • If there has previously been an unmatched call to buff .Get() • If there are no pending calls to buff .Get() • Exactly which pairs of calls are matched up is unspecified • Difficulties • In which thread the body runs ? • To which method call the final value is returned ?

  8. Specification • If return-type is async then the formal parameter list formals may not contain any ref or out parameter modifier • At most one method-header may have a non-async return-type. • If the chord has a method-header with return-type type, then body may use return statements with type expressions, otherwise body may use empty return statements. • All the formals appearing in method-headers must have distinct identifiers. • Two method-headers may not have both the same member-name and the same argument type signature.

  9. The method-headers must either all declare instance methods or all declare static methods • All method-headers with the same member-name and argument type signature must have the same return-type and identical sets of attributes and modifiers • Typing issues – async is a subtype of void • an async method may override a void one, • a void delegate may be created from an async method, and • an async method may implement a void method in an interface

  10. Programming Polyphonic C# • A simple example Put Chord Get Chord

  11. Reader writer lock • Problems with the above code • Fairness problem – starvation(writer)

  12. Reader Writer lock

  13. Combining Asynchronous Messages

  14. Active Objects

  15. Implementation • Translation from Polyphonic C# to plain C# • Converting state chords to state automata • synchronization state consists of the pending calls • threads for regular methods • messages for asynchronous methods • synchronization depends on – • presence or absence of pending calls • number of calls • actual parameters

  16. Performance issues – • Complete asynchronous chord is always expensive • asynchronous method • synchronous method • All asynchronous messages are present • Otherwise • Translation – • modularize the translated code by introducing auxiliary classes for queues and bitmasks • Queues – class that represents message queues

  17. Related work • The work is based on join calculus • Join java follows similar approach of using join calculus • Synchronization barriers in dataflow languages modeled in Petrinets are similar to chords.

  18. Future Work • Scope for optimizing the implementation • Lock optimization - There are situations when we could safely ‘fuse’ successive critical sections protected by the same lock. • Queue optimization - at most one pending call on a particular object could be compiled using private fields instead of queues • Thread optimization - Purely asynchronous chords can often be compiled to run in the invoking thread, rather than a new one

  19. Conclusion • Designed and implemented a join calculus-based extension of C# that is simple, expressive, and efficient. • Writing correct concurrent programs is considerably less difficult in Polyphonic C# than in ordinary C# • Implementation is constrained by the underlying threads-and-locks model

  20. QUESTIONS

More Related