Another CPU should only see the end result of a transaction. Assuming "freeing a block" involves changing the pointer to it the other CPU should not see the invalid pointer, if the read occurs while the transaction is active. Clearly however, if a program picks up some pointer and later does something with it there should be no expectation that it will still be valid if other processes are changing the state of things. I don't see this having much to do with replacing reader/writer locks for say scanning queues that might change, although it might be part of an implementation.
-----Ursprüngliche Nachricht----- Von: IBM Mainframe Assembler List [mailto:[email protected]] Im Auftrag von Binyamin Dissen Gesendet: Mittwoch, 19. September 2012 11:15 An: [email protected] Betreff: Re: The Transaction state (correction) 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.
