Ok, second try. Case 1. Non-TS picks up the pointer before TS starts. No problem (yet). Case 2. Non-TS picks up the pointer while TS is active which causes TS to abort. Non-TS gets the pointer. No problem (yet). Non-TS runs after TS ends. gets the pointer to P23. No problem here. It is irrelevant whether Non-TS is interrupted, subsequently abends or whatever. In Case 2 TS probably retries and so in Case 1 and 2 Non-TS may end up with an invalid pointer. This applies in any case if the first (Non-TS) thread picks up some pointer and expects it to remain valid while another process is changing that data but doesn't serialize the whole process. If your processing depends on that pointer still being valid later you need to serialize more than just the updating of the pointer, e.g. you update the chain (within a Transaction!) and keep the element for yourself and process at your leisure. Transactional Execution basically optimizes critical section processing e.g. changing links ! in a chain or updating multiple fields when others may be doing the same thing and doesn't provide (relatively) long term serialization of changes to data structures. There's various trade-offs here. If there's low contention there's no need for high performance serialization. If there's high contention you can't serialize long processes in this way since the chances of the transaction being aborted are then high. I'd be interested to know how PPA allows the processor to ensure a constrained transaction completes (mostly?)
-----Ursprüngliche Nachricht----- Von: IBM Mainframe Assembler List [mailto:[email protected]] Im Auftrag von Binyamin Dissen Gesendet: Donnerstag, 20. September 2012 14:24 An: [email protected] Betreff: Re: The Transaction state (was Model 2827 New Instructions) On Thu, 20 Sep 2012 07:39:29 -0400 Peter Relson <[email protected]> wrote: :>>From my read of the doc it appears that TS only serializes with other :>code :>>equally doing TS. I don't see how non-TS code running a linked-list is :>>protected if the TS code removes an item from the list. :>But it is. The point really is that the transactional remover cannot :>remove :>while the runner is running through that part of the queue because the :>runner is accessing data for "read" which conflicts with the remover's :>accessing of the same data for "write". Once the runner is beyond that :>point :>(or if it has not yet gotten up to that point) the removal can occur, so :>when the runner gets there it will find the update already done (or if it :>is beyond, it will not care that an earlier part of the queue has been :>changed). I am not sure that I understand. Non-TS is running a linked list. As it fetches the pointer to P22 from P21 it is interrupted. TS code runs, and attempts to set the forward pointer from P21 to P23 and attempts to reuse the P22 area for a different use. Does the TS routine receive a failure? Or is the non-TS code unprotected and when it resumes it will attempt to use P22 which is now a completely different block? -- 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.
