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 the queue 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"). Scanners
won't interfere with him. Other updaters (whether they're also in the
transaction state or not!) may interfere. I.e. they may try to update
the same fields at the same time. This is called a "collision"...
- 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 win, and the one who is will have to retry.
Of course, every updater should be in the TS state because if two
colliders are not... 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
At 9/18/2012 02:20 PM, McKown, John wrote:
I just read up on the Transaction Execution. I now need two things:
1. Aspirin; 2. a nap. I get the general concept, but the
restrictions are immense. I guess it is good for a *very* short
routine which does not update very much storage. The conditions
under which it can abort are a multitude. I wonder exactly what it
was that made IBM decide to implement it, as opposed to doing a CPU
"spin loop". I guess it is the only way to guarantee that another
CPU simply cannot observe an "in flight" set of updates by *any*
other code on *any* other CPU.
Now to read up on the other new instructions.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
[email protected] * www.HealthMarkets.com
