2

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 ?

glts
  • 21,808
  • 12
  • 73
  • 94
nish1013
  • 3,658
  • 8
  • 33
  • 46

1 Answers1

5

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.

Michał Marczyk
  • 83,634
  • 13
  • 201
  • 212
  • http://www.slideshare.net/SergeyStupin/clojure-concurrency-overview?from_search=1 but it says agent is for independent-uncoordinated , and transactions are only for coordinated aren't they? – nish1013 Sep 24 '13 at 09:08
  • @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.) – Rörd Sep 24 '13 at 10:11
  • @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? – nish1013 Sep 24 '13 at 12:43
  • @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. – Rörd Sep 24 '13 at 15:29
  • @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. – Rörd Sep 24 '13 at 15:34