←back to thread

Concurrency in Haskell: Fast, Simple, Correct

(bitbashing.io)
193 points ingve | 1 comments | 14 Apr 25 10:47 UTC | HN request time: 0.227s | source
Show context
FuckButtons ◴[17 Apr 25 03:24 UTC] No.43712793[source]▶
I 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?
replies(6): >>43713040 #>>43713043 #>>43713044 #>>43713127 #>>43714265 #>>43714335 #
1. mrkeen ◴[17 Apr 25 08:15 UTC] No.43714265[source]▶
Mutexes lock code, TVars lock data.

If you lock a section of code (to protect data), there's no guarantee against mutations of that data from other sections of code.

If you lock the data itself, you can freely pass it around and anyone can operate on it concurrently (and reason about it as if it were single-threaded).

It's the same approach as a transactional database, where you share one gigantic bucket of mutable state with many callers, yet no-one has to put acquire/release/synchronise into their SQL statements.