On Thu, 20 Sep 2012 10:42:24 -0500 "McKown, John" <[email protected]> wrote:
:>In your scenario, where the non-TS code uses a pointer "some time later", then it can suffer a problem because the TS code is not interrupted (because it is run after the non-TS code fetches the pointer), nor is the non-TS code interrupted (because it isn't TS code). To be absolutely safe, the pointer must only be found and subsequently used within code in a single TS code segment. I.e. you cannot fetch the pointer in TS code, end TS code section, then use the pointer and be guaranteed to be safe. :>As I indicated, to safely use "pointers" outside a single TS transaction, the "pointers" must be "smart", not just "plain-old" pointers to some piece of storage. In my reading, it appears Peter implied otherwise. I just wanted to confirm. :>> -----Original Message----- :>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER- :>> [email protected]] On Behalf Of Binyamin Dissen :>> Sent: Thursday, September 20, 2012 7:24 AM :>> To: [email protected] :>> Subject: 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. -- 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.
