Ah. I misunderstood your meanings of "delay", where I interpreted that as the CPU itself "stopping" as it does in a interruptible wait state. And "need" in "scanners and updaters all need to be in the TS state" as "are required to be in TS state in order to have a fetch or update cause a TS abort". A TS abort will occur regardless of the TS state of the scanner. I guess I still don't understand Ben's "he can quite easily be delayed". Why would a scanner in TS state be less likely to cause an TS abort (aka "delay") than not? I don't recall Ben's objection.
-- 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>
