Erlang and OTP in Action.pdf - Synrc

129
analogous to database transactions for controlling access to shared
memory in concurrent computing. It functions as an alternative to lockbased
synchronization, and is typically implemented in a lock-free way. A
transaction in this context is a piece of code that executes a series of reads
and writes to shared memory. These reads and writes logically occur at a
single instant in time; intermediate states are not visible to other
(successful) transactions.
The Magic Ball
To use a bit of illustration, lets say we had a baseball that I wanted to get signed by
every member of the 1949 Yankees. It’s a very special ball in that I can make copies on
demand and hand them out to whoever I would like. However, I am not giving them a
permanent copy, I am just letting them sign it and hand it back. So ten people come up
and ask to sign it. I magically make ten copies of the clean new ball. The fifth person I
gave a ball too happens to get back to me the quickest. I replace the ball in my hand with
the new ball number 5 just gave me. A few seconds later number 6 comes back having
signed his ball. I look at the ball in my hand and the ball he is giving to me and notice
that they are different. My ball has number 5s signature, the ball he is giving me has
number sixes signature. Uh oh, that’s not going to work. So I throw away number 6’s ball
and make a copy of the ball I currently have in my hand and hand it back to number 6
telling him to sign it. This repeates over and over again as the rest of the signers come
back having signed an out of date ball. In essence here, I am the gatekeeper and I make
sure that I always have the most recent ‘copy’ of the ball.
STM has a few benefits that aren't immediately obvious, from this
description. First and foremost STM is optimistic. Every thread does what it needs
to do without knowing or caring if another thread is working with the same data.
At the end of a manipulation, if everything is good and nothing has changed, then
the changes are committed. If problems or conflicts occur the change can be rolled
back and retried. The cool part of this is that there isn't any waiting for resources.
Threads can write to different parts of a structure without sharing any lock. The
bad part about this is that you have to retry failed commits. There is also some, not
insignificant, overhead involved with the transaction subsystem itself that causes a
performance hit. Additionally in certain situations there may be a memory hit, ie if
n processes are modifying the same amount of memory you would need O(n) times
memory to support the transaction. In general, for the programmer, this approach
is many times more manageable than the mainstream shared memory approach
and may be a useful way of taking advantage of concurrency. We still consider this
approach to be shared memory at its core but must admit that the position is an
ongoing argument between us and a number of our colleagues.
5.1.4 Dataflow - Futures and Promises
©Manning Publications Co. Please post comments or corrections to the Author Online forum:
http://www.manning-sandbox.com/forum.jspaforumID=454