Communication of sequential processes in .NET.

Question

I recently worked with Go, and it occurred to me that perhaps the same CSP model could be built into a future version of .NET. I'm not just talking about a new library that provides a channel type and a similar programming experience / model using existing thread primitives under the hood; I mean the implementation of the model throughout the VM and the compiler to create executable code that is comparable to Go (I believe that Go produces code that runs in an event loop)

Is it possible? Did you talk about this before? ... or I "drank too much kool-aid". I definitely go out of my depth in this matter from the point of view of a full understanding of how this can be realized.

Answer 1

Writing this from the point of view of someone more familiar with Go than .NET or Microsoft, as a rule, but trying to use sources more built-in in this world.

There are some forms of user-mode task switching in the Windows ecosystem, similar to what the Go scheduler does: the fibers return to Windows NT 3.51, it seems , and as a slightly more convenient option for developers, you can use user-mode scheduling to schedule OS flows from your own code. I also can not find .NET ( 1 , 2 ).

In a post on the fibers linked above, Larry Osterman explains some reasons why they were no longer used in 2005. Some reasons are specific fiber quirks in the Windows API, but others apply to user-mode scheduling more generally. Running a context switch currently takes microseconds; this is simply not a problem if you are not going to run hundreds of thousands of switches per second. And due to cache deficiencies, switching to another code that runs on different data may already cause delays in microseconds, even if they are fully executed in user mode. Purchases from user threads are nice to have, but there is no reason to assume that they are make-or-break.

You have asynchronous .NET programming tools that do not create OS-driven threads, although this is a different thing from user-driven threads. async / await makes it more convenient to perform an I / O operation in the background while you do other things, which is similar to some use of goroutines for asynchronous network material ( 1 , 2 ). In .NET, people tried to build coroutines on yield or async / await , but that doesn't mean it's a good idea.

I like Go a lot, but just as I advise people to write an idiomatic Go in Go, I would say write idiomatic C #, etc. in .NET. In both cases, everything will probably be fine.

If you encounter a problem that you think might include threads, you can always check the context switching statistics to see if you really do enough switching to the question, then if so, go back to your code to find out how you can bring things back under control. Anxiety later often sounds the alarm too soon when you do not have a working code, and all this is theoretical!