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>
