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. -- 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 Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----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.
