Concurrency in Haskell: Fast, Simple, Correct
bitbashing.io
Concurrency in Haskell: Fast, Simple, Correct
1–10 of 129 posts
Re: Concurrency in Haskell: Fast, Simple, Correct
#2It's maybe interesting to note that the `async` library in use here is very simple and easy to understand. Nearly every function is one or two lines. Likewise `TQueue` is extremely simple (and easy to prove correct) thanks to STM, and also generally has good performance.
Re: Concurrency in Haskell: Fast, Simple, Correct
#3In another life I will be a Haskell programmer
Re: Concurrency in Haskell: Fast, Simple, Correct
#4Rust has a bunch of these while being maintainable.
Re: Concurrency in Haskell: Fast, Simple, Correct
#5I thought it was a bit odd that the author claims there’s no mutexes in sight, the TVar is effectively a mutex guard unless I’m misunderstanding this? (I’ve written exactly 0 lines of Haskel). Or is the claim that the lack of ceremony and accidental complexity around threading is the real win for concurrency here?
Re: Concurrency in Haskell: Fast, Simple, Correct
#6In another life I will be a Haskell programmer
Yeah me too, I'll invest in bitcoin early, live like a hermit off a coast somewhere, and school kids on HN, "cabal hell! I'll scream, no, Conda hell with powershell hooks in vscode you ingrates, my llm"
Re: Concurrency in Haskell: Fast, Simple, Correct
#7In another life I will be a Haskell programmer
Why not python ?
Re: Concurrency in Haskell: Fast, Simple, Correct
#8I thought it was a bit odd that the author claims there’s no mutexes in sight, the TVar is effectively a mutex guard unless I’m misunderstanding this? (I’ve written exactly 0 lines of Haskel). Or is the claim that the lack of ceremony and accidental complexity around threading is the real win for concurrency here?
No, a TVar is not a mutex guard. A TVar is a software transactional memory (STM) variable. STM works just like a database: you batch together a sequence of operations into a transaction and then execute them. During execution of a transaction, all changes made to the contents of the TVar are stored in a transaction log. If some other transaction occurs during the execution then the whole thing is aborted and re-run.
This can take any ordinary Haskell data structure and give you a lock-free concurrent data structure with easy-to-use transactional semantics. How it performs is another matter! That depends on the amount of contention and the cost of re-playing transactions.
Re: Concurrency in Haskell: Fast, Simple, Correct
#9I thought it was a bit odd that the author claims there’s no mutexes in sight, the TVar is effectively a mutex guard unless I’m misunderstanding this? (I’ve written exactly 0 lines of Haskel). Or is the claim that the lack of ceremony and accidental complexity around threading is the real win for concurrency here?
A mutex locks the thread, which doesn't happen with TVar. For mutexes TMVar would be used.
Re: Concurrency in Haskell: Fast, Simple, Correct
#10I thought it was a bit odd that the author claims there’s no mutexes in sight, the TVar is effectively a mutex guard unless I’m misunderstanding this? (I’ve written exactly 0 lines of Haskel). Or is the claim that the lack of ceremony and accidental complexity around threading is the real win for concurrency here?
You are correct, Haskell has quite a few mutex-like types. MVar is one of them.
However, if memory serves me right, TVar is a building block for the transactional memory subsystem. The guard on TVar with, say, modifyTVar is not really stopping execution at entrance but simply indicating that the block modifies the variable. In my mental model, some magic happens in an STM block that checks if two concurrent STM blocks acted upon the same data at the same time, and if so, it reverts the computations of one of the blocks and repeats them with new data.
To my knowledge, Haskell is the only programming language (+runtime) that has a working transactional memory subsystem. It has been in the language for about 20 years, and in that time many have tried (and failed) to also implement STM.