I have reviewed the "Transactional Execution" section of the new
zProOps and I see that I need to make a correction of my earlier
description. Previously, I had believed that fetch accesses could not
lead to collisions. That is incorrect. Fetches (both transactional
and non-transactional) made against the same storage (cache lines
actually) as transactional stores give rise to collisions that cause
the (or a) storing transaction to abort. Consequently, the process
doing the nontransactional fetch will see only pre-transaction values
and will simply proceed as if nothing has happened.
So my revised description follows:
At 9/18/2012 02:46 PM, David Cole wrote [revised]:
The transaction state is expected to replace many instances of
acquiring either a latch or a lock. It's benefit arises because
latches/locks do not distinguish between a "shared" need vs. an
"exclusive" need, so all latches/locks are, effectively, "exclusive".
Consider a thousand processes needing to scan a queue and one
process, every year or so, updating that queue. The scan processes
do not need to defend against each other, only against the updater.
So a vast majority of the time, scanners are "unnecessarily"
delayed. "Unnecessary" in the sense that the updater just ain't
there, only other scanners.
With the transaction state, neither scanners nor updaters need to
acquire any latch or lock. In fact, the scanners don't need to
acquire anything at all. They can simply scan the queue and be
assured (a) their scan will both complete and succeed, and (b) they
will see all queue elements either prior to update, or after update,
but never mid-update; i.e. they will always see a coherent queue.
Only the updater needs to use the transaction state ("TS"). Other
updaters and scanners (whether they're also in the transaction state
or not!) may interfere. I.e. they may try to see or update the same
fields at the same time. When two processes attempt to access the
same storage at the same time, and one of those accesses is an
update, this is called a "collision"... (I'll call the participants
"colliders".)
- If both colliders are in the transaction state, then one will win
(and will proceed undisturbed) and one will lose (will TABORT and
will have to retry).
- If one is in the TS state and one is not, then the one who is not
will always win (and will see pre-update data), and the one who is
will always have to retry.
Scanners need not be in the TS state, but of course, every updater
should be. This is because if two updaters collide when neither is
in the TS state... well that is what you want to avoid.
IHTH
Dave Cole REPLY TO: [email protected]
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
