I haven’t used Async-Await ever, so the following will probably be moot.
But here I go:
I learned concurrency at Uni with C#. Most of it was meh/okay. The gist of
it is this:
- You have instances of Threads. Each one recieves a function to start in.
When they return, they end.
- Threads can be synchronized with “locks”. Basically, mutex.
- Threads can be syncronized with Monitors (idk how they work, it was kinda
cumbersome when I was taught).
And finally, a golden nugget:
- Threads can wait for signals/events. Signals are doors where threads wait
for someone to open the door and let them keep going.
Signals can be resat automatically (letting only one thread pass before
locking again) or manually.
Their design is pretty nice because they are a lot like single UI
event-driven tools (from reactive programming).
Everything else in C# threading at the time was pretty much meh. And
error-prone, if you only used locks. But I think Signals were a golden
nugget in a way. How would they fare in current multithreaded programming?
Idk. I have to read a lot about the state of the art now.
Thanks Chris for your manifesto. I’m reading it right now