3. it’s pretty much useless
unless you have:
concurrency
shared state
changes to state
Thursday, December 15, 11
4. the pitch
“It allows you to do
coordinated change
without the complexity
of locking.”
— Rich Hickey
http://www.infoq.com/interviews/hickey-clojure
Thursday, December 15, 11
5. kind of like
database transactions.
but in memory.
Thursday, December 15, 11
6. example
shared state 1 9 5 7 3 10 4
2 6 8
changing state 4
4
threads a
b c d
e
solution: do it atomically!
Thursday, December 15, 11
9. changing state
atomic (acts as one point in time)
consistent (from valid state to valid state)
isolated (changes are local until committed)
Thursday, December 15, 11
10. sharing state
mutate in
STM only!
coordinated independent
synchronous ref atom
asynchronous – agent receive message
and return
Thursday, December 15, 11
11. STM functions
ref reference to a collection
dosync transaction
set-ref set new value
alter set new value via a function
commute set new value and don’t block
ensure block writes by others
io! IllegalStateException
Thursday, December 15, 11
13. STM functions
ref reference to a collection
dosync transaction
set-ref set new value
alter set new value via a function
commute set new value and don’t block
ensure block writes by others
io! IllegalStateException
Thursday, December 15, 11
14. what to think about
is it okay if others make changes in parallel?
commute
multi-ref constraints?
ensure
Thursday, December 15, 11
15. how does it work?
MVCC, snapshot isolation
persistent data structures
on-commit evaluation
http://java.ociweb.com/mark/stm/article.html
Thursday, December 15, 11
