I have to admit, Ben, you are right: Both scanners and updaters do need to be in the TS state. Sorry for the error.
Still, Transactional Execution remains far better than latches/locks since (unlike with L/Ls) no holders of the TS state are delayed unless a collision actually occurs, and that would be only once in a very blue moon. Dave Cole At 9/19/2012 05:14 AM, you wrote:
On Wed, 19 Sep 2012 03:54:50 -0400 David Cole <[email protected]> wrote: :>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. Routine A fetches pointer to block X and is interrupted (non-TS) Routine B (TS) frees block X (TS) and completes TS Routine A (non-TS) is now redispatched with the orphan pointer. I don't see how A will handle this being non-TS. If A was TS, it seems that it would get the failure when the altered X is fetched. :>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 -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
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
