Does Clojure STM has a relationship with atom and agent forms?

Question

I am looking into the Concurrency programming in Clojure . http://clojure.org/concurrent_programming

I got to know that atom, ref and agent forms are used to maintain program state.

Only ref is used for coordinated updates , so dosync macro is used when performing changes.

So it is obvious that STM engine is involved at this point.

Just wanted to be clear about following doubt I have,

Does Clojure STM has a relationship with atom and agent forms too? or are they just utilized java.util.concurrent.atomic capabilities ?

Stoneware

Answer 1

The STM is related to Agents in that send, send-off and send-via, when called inside a dosync block, only take effect once (and if) the transaction successfully commits.

There is no relationship between the STM and Atoms.

Evelyne

slideshare.net/SergeyStupin/… but it says agent is for independent-uncoordinated , and transactions are only for coordinated aren't they? – Stoneware

@nish1013: Sending messages to an agent is a side-effect. Transactions may be tried multiple times, but you usually want side-effects to happen only once. (In particular, it makes sense to wrap all side-effecting operations (besides modifications of the ref) in a transaction in agents to achieve this behaviour.) – Canvasback

@Michał Marczyk"Sending messages to an agent is a side-effect" why it is a side effect? please explain. And also if we wrap side effect things in a transaction it could be triggered few times , so what you meant is if we remove refs from particular transaction that will still work fine as it will NEVER re-trigger the transaction. The reason not to re-trigger is there is nothing mutable in such as ref inside it. If we had a ref then it could be change during the transaction so when it comes to commit stage this would be notice hence will re trigger the transaction. Is my understanding correct? – Stoneware

@nish1013: Sorry, my wording was misleading. I didn't mean to suggest to wrap side-effecting operations in transactions generally, but rather that if a side-effect has to be caused in a transaction, it should be wrapped in an agent so that it will only be executed once. Sending a message to an agent is always a side-effect insofar as that the direct return value (the agent itself) is never the result you're really interested in. Either you want the agent to execute actual side-effects (like IO or memory mutation), or you want to dereference it later for the result of an expensive calculation. – Canvasback

@nish1013: And the "(besides modifications of the ref)" part was not a suggestion to leave such modifications out of transactions, but rather that these don't have to be wrapped in agents because coordinating these specific side-effects is already the core mechanic of transactions. – Canvasback