[Kiev] Seminar 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 was leading this seminar (yes, besides me, there were also people there, 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 are familiar guys from the teams in which I either worked or with whom we communicate quite closely. But man 8 was also from other teams and, it seems, not even from Luxoft. Due to the fact that most were all their own, the atmosphere was informal from the very beginning: the guys teased me, I, in turn, made them.
The workshop, in fact, was based on my two articles on asynchronous programming: “Asynchronous Programming and AsyncEnumerator” and “Introduction to Asynchronous Operations in C # 5” , as well as articles on the internal structure of iterators: “Iterators in C #” . The reactive extensions, which I was also going to consider, did not fit in decisively; considering only RXs of two hours is not enough, so I decided not to spray.
')
The result was a presentation of 50 slides, approximately with the following structure:
1. Acquaintance and all such bla-bla-bla.
2. Synchronous operations with examples, their advantages and disadvantages.
Before moving to asynchronous programming, you need to understand what is wrong with synchronous. In general, most people are familiar with these problems, but it was useful to talk about such concepts as CPU-Bound and IO-Bound operations so that everyone understands what is going on.
3. Asynchronous programming patterns 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 the Event-Based Async Pattern.
4. Disadvantages of existing patterns
Although this is just one slide, but it is important enough to allocate it into a separate section. Yet it is the flaws of using existing asynchronous programming patterns, such as complexity of use and perversion of the flow of execution, led comrades such as Jeff Richter and Eric Meijer to come up with all sorts of crap, like AsyncEnumerator classes and libraries like Reactive Extensions . I am already silent for some individuals who have decided to add asynchrony support to a couple of very popular programming languages ​​(*).
5. PowerThreading library and, in particular, the AsyncEnumerator class.
The importance of Richter's creation lies in the fact that it is this very idea that 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 is much easier to deal with the “straightening” of the flow of execution than immediately to the consideration of await and async. In fact, the only concept that needs to be mastered is blocks of iterators.
5.1. Distraction from the topic: iterator blocks.
I suspected that it was impossible to explain how AsyncEnumerator works without understanding how iterator blocks work. And I apparently did the right thing to add 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 a “pattern break” that the yield return arranges. Throughout the report, I returned to the topic of iterators and reminded about their internal structure.
6. Asynchronous operations in C # 5. Keywords async and await.
This is where I made the most significant mistake: I paid too little attention to the Task classes. In fact, the new features of asynchronous programming are built on the basis of two concepts: (1) “dislocation” of the execution flow, which is very similar to blocks of iterators and (2) classes of “tasks” ( Task and Task <T> ). But, more or less in detail, I considered only the first component, and the second - I considered only superficially. Therefore, I had to give examples on the go with tasks, with all their continuations, synchronization contexts and interrelations with BeginXXX / EndXXX and show them on the fingers.
The main consideration of the capabilities of await and async was conducted in the context of the material already studied: we replace IEnumerator <int> with async, and the yield return with await and we move from AsyncEnumerator to new features C # 5.0.
7. Conclusion, questions, etc.
Summary of the seminar
Today there was an additional analysis of the flight with colleagues, as a result of which the following conclusions were made. What needs to be worked on:
1. I periodically scored on slides and told from myself, sometimes looking ahead, ahead of the slides.
2. Not all the terms 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. To tell from simple to complex, and not vice versa. There were cases when I initially superficially touched on some topics, and only then considered them in more detail. Because of this, the guys had additional questions, and there was some confusion.
4. Communicate more with the audience. I tried to ask questions and sometimes even foolish to joke, but it is worth engaging 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 flow of asynchronous code execution.
6. Yes, I paid too little attention to tasks (Task, Task <T>, etc.). You 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 a 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 to look at yourself from the outside and to conduct a more detailed analysis of errors.
What you liked:
Despite the fact that there are a number of issues that need to be worked on, the workshop was generally successful. 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 “their own” entered the discussion, but the guys who personally did not know me, nodded a maximum and raised their hands to questions like: “Do you know who Richter is?”.
In general, I am ready to repeat and consider either this topic again, or touch on reactive extensions that many guys are interested in.
From here you can download: (1) a presentation ; (2) test design .
-----------------------------
(*) This is a subtle hint at Anders Hejlsberg with a company who are going to add features for asynchronous programming in C # and VB.NET;)
Some twenty people were present, most of whom are familiar guys from the teams in which I either worked or with whom we communicate quite closely. But man 8 was also from other teams and, it seems, not even from Luxoft. Due to the fact that most were all their own, the atmosphere was informal from the very beginning: the guys teased me, I, in turn, made them.
The workshop, in fact, was based on my two articles on asynchronous programming: “Asynchronous Programming and AsyncEnumerator” and “Introduction to Asynchronous Operations in C # 5” , as well as articles on the internal structure of iterators: “Iterators in C #” . The reactive extensions, which I was also going to consider, did not fit in decisively; considering only RXs of two hours is not enough, so I decided not to spray.
')
The result was a presentation of 50 slides, approximately with the following structure:
1. Acquaintance and all such bla-bla-bla.
2. Synchronous operations with examples, their advantages and disadvantages.
Before moving to asynchronous programming, you need to understand what is wrong with synchronous. In general, most people are familiar with these problems, but it was useful to talk about such concepts as CPU-Bound and IO-Bound operations so that everyone understands what is going on.
3. Asynchronous programming patterns 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 the Event-Based Async Pattern.
4. Disadvantages of existing patterns
Although this is just one slide, but it is important enough to allocate it into a separate section. Yet it is the flaws of using existing asynchronous programming patterns, such as complexity of use and perversion of the flow of execution, led comrades such as Jeff Richter and Eric Meijer to come up with all sorts of crap, like AsyncEnumerator classes and libraries like Reactive Extensions . I am already silent for some individuals who have decided to add asynchrony support to a couple of very popular programming languages ​​(*).
5. PowerThreading library and, in particular, the AsyncEnumerator class.
The importance of Richter's creation lies in the fact that it is this very idea that 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 is much easier to deal with the “straightening” of the flow of execution than immediately to the consideration of await and async. In fact, the only concept that needs to be mastered is blocks of iterators.
5.1. Distraction from the topic: iterator blocks.
I suspected that it was impossible to explain how AsyncEnumerator works without understanding how iterator blocks work. And I apparently did the right thing to add 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 a “pattern break” that the yield return arranges. Throughout the report, I returned to the topic of iterators and reminded about their internal structure.
6. Asynchronous operations in C # 5. Keywords async and await.
This is where I made the most significant mistake: I paid too little attention to the Task classes. In fact, the new features of asynchronous programming are built on the basis of two concepts: (1) “dislocation” of the execution flow, which is very similar to blocks of iterators and (2) classes of “tasks” ( Task and Task <T> ). But, more or less in detail, I considered only the first component, and the second - I considered only superficially. Therefore, I had to give examples on the go with tasks, with all their continuations, synchronization contexts and interrelations with BeginXXX / EndXXX and show them on the fingers.
The main consideration of the capabilities of await and async was conducted in the context of the material already studied: we replace IEnumerator <int> with async, and the yield return with await and we move from AsyncEnumerator to new features C # 5.0.
7. Conclusion, questions, etc.
Summary of the seminar
Today there was an additional analysis of the flight with colleagues, as a result of which the following conclusions were made. What needs to be worked on:
1. I periodically scored on slides and told from myself, sometimes looking ahead, ahead of the slides.
2. Not all the terms 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. To tell from simple to complex, and not vice versa. There were cases when I initially superficially touched on some topics, and only then considered them in more detail. Because of this, the guys had additional questions, and there was some confusion.
4. Communicate more with the audience. I tried to ask questions and sometimes even foolish to joke, but it is worth engaging 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 flow of asynchronous code execution.
6. Yes, I paid too little attention to tasks (Task, Task <T>, etc.). You 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 a 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 to look at yourself from the outside and to conduct a more detailed analysis of errors.
What you liked:
Despite the fact that there are a number of issues that need to be worked on, the workshop was generally successful. 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 “their own” entered the discussion, but the guys who personally did not know me, nodded a maximum and raised their hands to questions like: “Do you know who Richter is?”.
In general, I am ready to repeat and consider either this topic again, or touch on reactive extensions that many guys are interested in.
From here you can download: (1) a presentation ; (2) test design .
-----------------------------
(*) This is a subtle hint at Anders Hejlsberg with a company who are going to add features for asynchronous programming in C # and VB.NET;)
Source: https://habr.com/ru/post/123665/
All Articles