[Kiev] Workshop on asynchronous programming in .Net
Yesterday I was at the first seminar in general and on .Net in particular, and it just so happened that I conducted the seminar (yes, besides me, there were people there too, really). The seminar was devoted to asynchronous programming on the .Net platform , which took place yesterday at the Luxoft training center.
Some twenty people were present, most of whom were familiar guys from teams in which I either worked, or with whom we communicate quite closely. But 8 people were from other teams and, it seems, not even from Luxoft. Due to the fact that they were basically all their own, the atmosphere from the very beginning was informal: the guys teased me, I, in turn, them.
The workshop, in fact, was based on two of my articles on asynchronous programming:“Asynchronous Programming and AsyncEnumerator” and “Introducing Asynchronous Operations in C # 5” , as well as articles on the internal structure of iterators: “Iterators in C #” . Reactive extensions, which I was also going to consider, decidedly did not fit in; for consideration only RX-s two hours will not be enough, so I decided not to spray.
The result was a presentation of 50 slides, with approximately the following structure:
1. Acquaintance and all that blah blah blah.
2. Synchronous operations with examples, their advantages and disadvantages.
Before moving on to asynchronous programming, you need to understand what is wrong with synchronous. In general, most of the people are familiar with these problems, but it was useful to talk about concepts such as CPU-Bound and IO-Bound operations so that everyone understood what they were talking about.
3. Patterns of asynchronous programming in .Net: (1) Classical Async Pattern and (2) Event-Based Async Pattern .
Almost every .Net programmer knows about BeginXXX / EndXXX methods and most of them worked with the BackgroundWorker class. However, not everyone knows that BeginXXX / EndXXX methods are a classic asynchronous programming pattern, and BackgroundWorker is a typical representative of Event-Based Async Pattern.
4. Disadvantages of existing patterns.
Although this is just one slide, it is important enough to separate it into a separate section. Nevertheless, it is precisely the drawbacks of using existing patterns of asynchronous programming, such as complexity of use and perversion of the flow of execution, that prompted comrades such as Jeff Richter and Eric Meyer to come up with all kinds of crap, such as AsyncEnumerator classes and libraries, such as Reactive Extensions. I am already silent for some individuals who decided to add support for asynchrony to a couple of very popular programming languages (*).
5. The PowerThreading library and, in particular, the AsyncEnumerator class.
The importance of Richter’s creation lies in the fact that this very idea underlies the new language constructs of the C # 5 language: await and async. But, since this class is built on the basis of a minimum of additional language constructs and does not use any other third-party libraries, it’s much easier to figure out how to “straighten” the execution flow than to immediately go on to consider await and async. In fact, the only concept that needs to be mastered is iterator blocks.
5.1. Distraction from the topic: iterator blocks.
I suspected that explaining how the AsyncEnumerator class works without understanding how iterator blocks work is impossible. And I apparently did the right thing by adding this section to the report; many guys are well aware of what iterator blocks are and more or less represent how they are arranged, but not everyone understands the consequences of the “template break” that yield return suits. Throughout the report, I returned to the topic of iterators and recalled their internal structure.
6. Asynchronous operations in C # 5. Keywords async and await.
Here, I probably made the most significant mistake: I paid too little attention to the consideration of Task classes. In fact, the new features of asynchronous programming are based on two concepts: (1) “dislocation” of the execution thread, which is very similar to iterator blocks and (2) classes of “tasks” ( Task and Task <T> ). But, in more or less detail, I examined only the first component, and the second - examined only superficially. Therefore, I had to give examples with tasks on the go, with all their continuations, contexts of synchronization and interconnection with BeginXXX / EndXXX and show them on my fingers.
The main consideration of await and async features was carried out in the context of the already studied material: we replace IEnumerator <int> with async, and yield return with await and we are moving from AsyncEnumerator to the new features of C # 5.0.
7. Conclusion, questions, etc.
Workshop Summary
Today there was an additional analysis of the flight with colleagues, as a result of which the following conclusions were made. Things to work on:
1. I occasionally scored on slides and spoke on my own, sometimes running ahead, ahead of the slides.
2. Not all the terms that I used were understandable to people. For example, I could talk about synchronization contexts, implying that everyone is familiar with these concepts. Since this was not always the case, part of the audience was lost.
3. Talk from simple to complex, and not vice versa. There were cases when at first I superficially dealt with some topics, and only then examined them in more detail. Because of this, the guys had additional questions, and some misunderstanding appeared.
4. Communicate more with the audience. I tried to ask questions and sometimes it’s even silly to joke, but it’s worth involving the audience more.
5. More pictures and less code. In general, there was a lot of code on the slides, and in the additional materials it was even more. Many concepts, especially iterator blocks and, accordingly, all this asynchronous crap, need to be visualized more strongly. Code is not the best demonstration of the complex thread of asynchronous code execution.
6. Yes, I paid too little attention to tasks (classes of Task, Task <T>, etc.). We need more examples with all sorts of ContinueWith and the like, and better in the form of drawings, with an explicit demonstration of the flow of execution.
7. In the code examples, there were not enough line numbers, but I did not have the laser pointer. Because of this, sometimes I had to additionally run around the hall and tell something on my fingers.
8. The next time you need to record this case in order to look at yourself from the side and conduct a more detailed analysis of errors.
What I liked:
Despite the fact that there are a number of issues that need to be worked on, the seminar as a whole was a success. I liked the fact that I liked to conduct this seminar and the audience liked to listen to it. The listeners were responsive and understanding. True, only “my own” entered into the discussion, but the guys who did not personally know me nodded and raised their hands to the maximum, asking questions like: “Do you know who Richter is?”
In general, I am ready to repeat and consider either this topic again, or touch on the jet extensions, which many guys are interested in.
Here you can download: (1) a presentation ; (2) test projection .
-----------------------------
(*) This is a subtle reference to Anders Halesberg with a company who is going to add features for asynchronous programming in C # and VB.NET;)
Some twenty people were present, most of whom were familiar guys from teams in which I either worked, or with whom we communicate quite closely. But 8 people were from other teams and, it seems, not even from Luxoft. Due to the fact that they were basically all their own, the atmosphere from the very beginning was informal: the guys teased me, I, in turn, them.
The workshop, in fact, was based on two of my articles on asynchronous programming:“Asynchronous Programming and AsyncEnumerator” and “Introducing Asynchronous Operations in C # 5” , as well as articles on the internal structure of iterators: “Iterators in C #” . Reactive extensions, which I was also going to consider, decidedly did not fit in; for consideration only RX-s two hours will not be enough, so I decided not to spray.
The result was a presentation of 50 slides, with approximately the following structure:
1. Acquaintance and all that blah blah blah.
2. Synchronous operations with examples, their advantages and disadvantages.
Before moving on to asynchronous programming, you need to understand what is wrong with synchronous. In general, most of the people are familiar with these problems, but it was useful to talk about concepts such as CPU-Bound and IO-Bound operations so that everyone understood what they were talking about.
3. Patterns of asynchronous programming in .Net: (1) Classical Async Pattern and (2) Event-Based Async Pattern .
Almost every .Net programmer knows about BeginXXX / EndXXX methods and most of them worked with the BackgroundWorker class. However, not everyone knows that BeginXXX / EndXXX methods are a classic asynchronous programming pattern, and BackgroundWorker is a typical representative of Event-Based Async Pattern.
4. Disadvantages of existing patterns.
Although this is just one slide, it is important enough to separate it into a separate section. Nevertheless, it is precisely the drawbacks of using existing patterns of asynchronous programming, such as complexity of use and perversion of the flow of execution, that prompted comrades such as Jeff Richter and Eric Meyer to come up with all kinds of crap, such as AsyncEnumerator classes and libraries, such as Reactive Extensions. I am already silent for some individuals who decided to add support for asynchrony to a couple of very popular programming languages (*).
5. The PowerThreading library and, in particular, the AsyncEnumerator class.
The importance of Richter’s creation lies in the fact that this very idea underlies the new language constructs of the C # 5 language: await and async. But, since this class is built on the basis of a minimum of additional language constructs and does not use any other third-party libraries, it’s much easier to figure out how to “straighten” the execution flow than to immediately go on to consider await and async. In fact, the only concept that needs to be mastered is iterator blocks.
5.1. Distraction from the topic: iterator blocks.
I suspected that explaining how the AsyncEnumerator class works without understanding how iterator blocks work is impossible. And I apparently did the right thing by adding this section to the report; many guys are well aware of what iterator blocks are and more or less represent how they are arranged, but not everyone understands the consequences of the “template break” that yield return suits. Throughout the report, I returned to the topic of iterators and recalled their internal structure.
6. Asynchronous operations in C # 5. Keywords async and await.
Here, I probably made the most significant mistake: I paid too little attention to the consideration of Task classes. In fact, the new features of asynchronous programming are based on two concepts: (1) “dislocation” of the execution thread, which is very similar to iterator blocks and (2) classes of “tasks” ( Task and Task <T> ). But, in more or less detail, I examined only the first component, and the second - examined only superficially. Therefore, I had to give examples with tasks on the go, with all their continuations, contexts of synchronization and interconnection with BeginXXX / EndXXX and show them on my fingers.
The main consideration of await and async features was carried out in the context of the already studied material: we replace IEnumerator <int> with async, and yield return with await and we are moving from AsyncEnumerator to the new features of C # 5.0.
7. Conclusion, questions, etc.
Workshop Summary
Today there was an additional analysis of the flight with colleagues, as a result of which the following conclusions were made. Things to work on:
1. I occasionally scored on slides and spoke on my own, sometimes running ahead, ahead of the slides.
2. Not all the terms that I used were understandable to people. For example, I could talk about synchronization contexts, implying that everyone is familiar with these concepts. Since this was not always the case, part of the audience was lost.
3. Talk from simple to complex, and not vice versa. There were cases when at first I superficially dealt with some topics, and only then examined them in more detail. Because of this, the guys had additional questions, and some misunderstanding appeared.
4. Communicate more with the audience. I tried to ask questions and sometimes it’s even silly to joke, but it’s worth involving the audience more.
5. More pictures and less code. In general, there was a lot of code on the slides, and in the additional materials it was even more. Many concepts, especially iterator blocks and, accordingly, all this asynchronous crap, need to be visualized more strongly. Code is not the best demonstration of the complex thread of asynchronous code execution.
6. Yes, I paid too little attention to tasks (classes of Task, Task <T>, etc.). We need more examples with all sorts of ContinueWith and the like, and better in the form of drawings, with an explicit demonstration of the flow of execution.
7. In the code examples, there were not enough line numbers, but I did not have the laser pointer. Because of this, sometimes I had to additionally run around the hall and tell something on my fingers.
8. The next time you need to record this case in order to look at yourself from the side and conduct a more detailed analysis of errors.
What I liked:
Despite the fact that there are a number of issues that need to be worked on, the seminar as a whole was a success. I liked the fact that I liked to conduct this seminar and the audience liked to listen to it. The listeners were responsive and understanding. True, only “my own” entered into the discussion, but the guys who did not personally know me nodded and raised their hands to the maximum, asking questions like: “Do you know who Richter is?”
In general, I am ready to repeat and consider either this topic again, or touch on the jet extensions, which many guys are interested in.
Here you can download: (1) a presentation ; (2) test projection .
-----------------------------
(*) This is a subtle reference to Anders Halesberg with a company who is going to add features for asynchronous programming in C # and VB.NET;)