The following modification of Ben's example is an example of needing both Routine A & B to be in TS state. It does require a multi-processor LPAR.
Routine A, on CP 0: TBEGIN; scan, find, and use pointer; TEND Routine B, on CP 1: TBEGIN; scan, find, and update structure; TEND I say at least 2 CPs because a TS state will abort if an interrupt occurs. So if on a single CP LPAR, either routine will TBEGIN/TEND, or abort because it was interrupted; which interrupt is required to switch to the other routine. Routine A must use the pointer in the TS state or it could be interrupted after it exits TS state. This is because an interrupt could cause a switch to Routine B at which point, it updates the structure in the TS state, and shortly after exiting does a FREE on some area whose pointer was gotten by Routine A. Now, on a multi-CP LPAR would be critical that Routine A never update any storage. If it does, I think it should be single threaded. To be explicit as to why: if it were not single threaded, and if it is "popular", then the likelihood of an abort will increase as the number of CPs in the LPAR increases. Makes me nervous. -- 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 McKown, John > Sent: Wednesday, September 19, 2012 9:12 AM > To: [email protected] > Subject: Re: The Transaction state (correction) > > OK, I found Ben's objection and see why it is desirable for a scanner > to be in TS state. I agree it is better for the scanner to enter the TS > state in order to avoid an orphan pointer error. However, the TS state > cannot use "restricted" instructions. > <quote> > 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. > </quote> > > I don't see how Routine B can free block X. Routine B cannot do a > FREEMAIN or a STORAGE RELEASE as these invoke "Restricted" instructions > (SVC or PC). > > -- > 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 David Cole > > Sent: Wednesday, September 19, 2012 8:43 AM > > To: [email protected] > > Subject: Re: The Transaction state (correction) > > > > Sorry, I use the word "delayed" in an informal sense. Yes, if a > > collision occurs, the TS state is aborted, and the recipient of that > > abortal will have to retry. That, in an informal sense, amounts to a > > "delay" in what the collider was trying to do. > > > > WRT Ben's objection, if a scanner is not in the TS state, then (as > > Ben points out) he can quite easily be delayed. This is why my prior > > understanding was incorrect. And this is why both scanners and > > updaters all need to be in the TS state. > > > > Dave > > > > > > > > > > At 9/19/2012 08:52 AM, McKown, John wrote: > > >I must have total misunderstood TS state. I was under the impression > > >that the TS would abort if *any* code read or updated any storage > > >updated by the TS code. TS state should abort if any interrupt > > >occurs while in TS state, even an I/O or External (e.g. timer) > > interrupt. > > >This means that the "unit of work" (TCB or SRB) cannot be suspended > > >or switch to another CPU. > > >It would also abort if the TS code tried to use any "unsupported" > > >(by TS state) instruction (such as SVC, LAE, et al.). > > > I really don't understand what you mean by "no holders of the TS > > > state are delayed unless a collision actually occurs". I didn't > > > see anything like "delayed" associated with TS state, only > > > "aborted". I guess "delayed" could mean that the TS code needs to > > > be rerun and this extra CPU usage "delays" the results. > > > > > >-- > > >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]<mailto:[email protected]> > > >* www.HealthMarkets.com<http://www.HealthMarkets.com>
