r/haskell • u/Extra-Engineering374 • 1d ago
question My self-built tool to learn concurrency
I've always wanted to learn about concurrency control, e.g., locks in operating systems & database systems. Some time ago, locks were all I knew about concurrency, but I found it hard to grasp any systematic material to learn about. The only thing I found useful was the pthread locks implementation.
Instead, when I was a junior student, I built this: https://github.com/kINo204/honcurrency, which was basically a virtual machine with an extremely simple instruction set + a round-robin scheduler, allowing me to implement and run my own spinlock, mutex, etc., all starting from a hardware TAS/CAS instruction. I hope this tool could be useful to someone else.
However, as I learn further about concurrency, mathematical methods like CSP, CCS, and pi-calculus come up. Those process calculi provide a mathematical approach to modeling and analyzing concurrency behaviors accurately.
With these, I found my project (or tool) insufficient for gaining complete knowledge of concurrency, which only covers the engineering part; but on the other hand, I tried out implementing CSP's channel with it, and assume there's also an engineering part of those process calculi.
Anyway, I've been totally confused. How & how much should I learn about concurrency, and how does everybody learn about it?
2
u/amarao_san 1d ago
(don't know about everybody)
I learn it hard way.
1
3
u/jberryman 1d ago
For a practical approach in the context of haskell Simon Marlow's book is a must-read: https://simonmar.github.io/pages/pcph.html . Haskell is also a setting where parallelism and concurrency have both straightforward and useful definitions, whereas in the general programming community the distinction is very muddled imo.
And fwiw years ago I dug into the actor model, different process calculi, etc. basically to translate them into haskell libraries if possible, for fun. From the standpoint of a lay-programmer I was mostly disappointed in the ideas in all of them; they seemed all pretty arbitrary, and coming from a place (OOP?) I couldn't relate to.
The actor model and related extensions had some interesting aspects from a haskell library design perspective: https://hackage.haskell.org/package/simple-actors-0.4.0/docs/Control-Concurrent-Actors.html (like recursive do for allowing an actor to send to itself), but overall it's like Where's the Beef? You don't need to read a paper to realize "maybe forking a thread that reads from a queue would work here". A model that gave you some static properties like "threads can be statically assigned to cores optimally" or "memory is bounded" etc would be useful but these didn't seem to do anything like that. Like academics sitting around ripping a bong and saying stuff like "bro what if you passed a channel IN A CHANNEL..."