3 ms·

I think you misunderstand STM. STM is used to group and apply a few micro-operations, within a single function, but not many or over multiple functions, certain

I think you misunderstand STM. STM is used to group and apply a few micro-operations, within a single function, but not many or over multiple functions, certainly not over multiple modules. It is not really for rebounding from exceptions in the general sense, as transactions are used in an RDBMS. It's more to keep the system in a stable state, something locks are usually used for in multi-threaded programming. Just as locks are best applied as fine-grained as possible, so is STM.

jrockway 15y ago
The goal of STM is to be composable, unlike locks: http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/stm.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers... The title of the paper is "Compsable Memory Transactions", and here's an excerpt: As we show, STM can be expressed particularly elegantly in a declarative language, and we are able to use Haskell’s type system to give far stronger guarantees than are conventionally possible. Furthermore transactions are compositional: small transactions can be glued together to form larger transactions.
- rbranson 15y ago
  Sure, just as you'd understand a library or function to be "thread safe" it could be considered "transactional." I'm saying STM is to be used in as fine a grain as possible, even if it's composing "larger grains." Just as thread-safety doesn't mean entering a shared, global critical section at the beginning of every function, STM doesn't mean that every block of code should be wrapped in a transaction. STM should really only be applied to writes that would cause the system to be in an improper state if partially applied.
  - jrockway 15y ago
    I'm not sure I agree. Reads also need to be in transactions in order to prevent deadlocks. I think the paper I linked is pretty accessible, so it's worth a read. I agree that most of your program should be pure, though, but that's just a good practice in general, not something tied to transactional memory.
scott_s 15y ago
In an object-oriented language, I think it's unrealistic to assume that transactions will not cross module boundaries.
jerf 15y ago
STM is pointless if it only works on just the tiniest possible transactions. Wrap a lock around the tiny transactions and call it a day. Without the composability, STM has no appeal. Yes, you still don't want long-running transactions and you will seek to minimize them, but the entire point is that you can write an STM action that may cross a few modules coming from different authors and put a selection of such actions together, and one must only apply normal amounts of thought to such minimization instead of insane amounts of thought and effort. It may be worth pointing out that I've made non-trivial use of the Haskell implementation. For Haskellers and Clojure programmers, STM isn't a pie-in-the-sky tech, it's a relatively straightforward library, because if you can manage effects or build it into your language very early (respectively), STM is almost boringly easy to implement. It's only hard (to the point of apparent impossibility) if you try to bodge it onto an existing imperative language.

jrockway 15y ago

The goal of STM is to be composable, unlike locks: http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/stm.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers... The title of the paper is "Compsable Memory Transactions", and here's an excerpt: As we show, STM can be expressed particularly elegantly in a declarative language, and we are able to use Haskell’s type system to give far stronger guarantees than are conventionally possible. Furthermore transactions are compositional: small transactions can be glued together to form larger transactions.

rbranson 15y ago
Sure, just as you'd understand a library or function to be "thread safe" it could be considered "transactional." I'm saying STM is to be used in as fine a grain as possible, even if it's composing "larger grains." Just as thread-safety doesn't mean entering a shared, global critical section at the beginning of every function, STM doesn't mean that every block of code should be wrapped in a transaction. STM should really only be applied to writes that would cause the system to be in an improper state if partially applied.
- jrockway 15y ago
  I'm not sure I agree. Reads also need to be in transactions in order to prevent deadlocks. I think the paper I linked is pretty accessible, so it's worth a read. I agree that most of your program should be pure, though, but that's just a good practice in general, not something tied to transactional memory.

scott_s 15y ago

In an object-oriented language, I think it's unrealistic to assume that transactions will not cross module boundaries.

jerf 15y ago

STM is pointless if it only works on just the tiniest possible transactions. Wrap a lock around the tiny transactions and call it a day. Without the composability, STM has no appeal. Yes, you still don't want long-running transactions and you will seek to minimize them, but the entire point is that you can write an STM action that may cross a few modules coming from different authors and put a selection of such actions together, and one must only apply normal amounts of thought to such minimization instead of insane amounts of thought and effort. It may be worth pointing out that I've made non-trivial use of the Haskell implementation. For Haskellers and Clojure programmers, STM isn't a pie-in-the-sky tech, it's a relatively straightforward library, because if you can manage effects or build it into your language very early (respectively), STM is almost boringly easy to implement. It's only hard (to the point of apparent impossibility) if you try to bodge it onto an existing imperative language.