←back to thread

193 points ingve | 1 comments | | HN request time: 0.001s | source
Show context
FuckButtons ◴[] 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 #
dsign ◴[] No.43713044[source]
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.

replies(2): >>43713050 #>>43713083 #
whateveracct ◴[] No.43713083[source]
I think Clojure has some kind of STM too?

Haskell's STM is pretty world-class though. That's fair to say :)

replies(1): >>43713157 #
dwohnitmok ◴[] No.43713157[source]
Clojure's STM never really took off because, for various reasons, it's not as easy to compose as Haskell's (where you can build up a big library of STM blocks and piece them together at the very edges of your program). As such Clojure's STM implementation doesn't actually have a great reputation within the Clojure ecosystem where it isn't usually used in most production codebases (whereas in Haskell STM is often one of the first tools used in any production codebase with concurrency).

Basically it's the difference between focusing only on transactional variables without having a good way of marking what is and isn't part of a larger transaction and having a higher-order abstraction of an `STM` action that clearly delineates what things are transactions and what aren't.

replies(2): >>43714468 #>>43718199 #
eduction ◴[] No.43718199[source]
My impression at least watching chatter over the last several years isn’t that it has a bad reputation but rather that people haven’t found a need for it, atoms are good enough for vast bulk of shared mutable state. Heck even Datomic, an actual bona fide database, doesn’t need STM it’s apparently all just an atom.

But I’ve never heard someone say it messed up in any way, that it was buggy or hard to use or failed to deliver on its promises.

replies(1): >>43719540 #
robto ◴[] No.43719540[source]
Clojure atoms use STM, though. I've been writing Clojure for almost a decade now, it's not that STM isn't great, it's just that immutable data will carry you a very long way - you just don't need coordinated mutation except in very narrow circumstances. In those circumstances STM is great! I have no complaints. But it just doesn't come up very often.
replies(2): >>43719854 #>>43724093 #
1. dwohnitmok ◴[] No.43719854[source]
I would say to the contrary it would come up all the time if the right idioms were in place.

For example, when it comes to concurrent access to a map the Clojure community generally forces a dichotomy, either stick a standard Clojure map in an atom and get fully atomic semantics at the expense of serial write performance or use a Java ConcurrentMap at the expense of inter-key atomicity (or do a more gnarly atom around a map itself containing atoms which gets quite messy quite fast).

Such a stark tradeoff doesn't need to exist! In theory STM gives you exactly the granularity you need where you can access the keys that you need atomicity for and only those keys together while allowing concurrent writes to anything else that doesn't touch those keys (this is exactly how e.g. the stm-containers library for Haskell works that's linked elsewhere).