Communicating Sequential Processes in .NET [closed]

Question

I have been working with Go recently and it occurred to me that perhaps the same CSP model could be built into a future version of .NET. I'm not simply talking about a new library that provides a channel type and a similar programming experience/model using the existing thread primitives under the hood; I mean implementing the model throughout the VM and compiler to produce executable code that is comparable to Go (I believe Go produces code that executes on an event-loop)

Is this feasible? Has it been talked about before?...or have I been 'drinking too much kool-aid'. I'm definitely way out of my depth on this one in terms of fully understanding how this might be implemented.

Answer 1

Writing this from the perspective of someone more familiar with Go than .NET or Microsoft ecosystems generally, but trying to use sources more embedded in that world.

The Windows ecosystem does include some forms of user-mode task switching similar to what Go's scheduler does: fibers go back to Windows NT 3.51 it seems, and as a slightly more developer-friendly option, user-mode scheduling, can be used to schedule OS threads from your own code. Neither is exposed to .NET as far as I can find (1, 2).

In the post about fibers linked above, Larry Osterman explains some reasons they were no longer heavily used by 2005. Some reasons are specific quirks of fibers in the Windows API, but others apply to user-mode scheduling more generally. Executing a context switch takes microseconds these days; it just isn't a problem unless you're expecting to do hundreds of thousands of switches per second. And because of cache misses, switching to different code operating on different data might already cause delays of microseconds, even if done entirely in user mode. The gains from user threads are nice to have, but there's no reason to assume they're make-or-break.

You do have asynchronous programming tools in .NET that don't create OS-managed threads, though that's a different thing from user-managed threads. async/await make it more convenient to have an I/O operation running in the background while you do other stuff, which is similar to some uses of goroutines for asynchronous network stuff (1, 2). In .NET, people have tried to build coroutines on yield or async/await, but that does not mean it's a good idea.

I like Go plenty, but just as I advise folks to write idiomatic Go in Go, I'd say write idiomatic C#, etc. in .NET. In both cases, it's probably gonna be fine.

If you do find yourself with a problem you think might involve threads, you can always check on context switch stats to see if you really are doing enough switches to matter, then if so go back to your code to figure out how you might get things back under control. Worrying later often beats worrying too early, when you don't have working code and it's all theoretical!