On Sep 22, 2012, at 13:55, Binyamin Dissen wrote: > On Fri, 21 Sep 2012 08:20:38 -0700 Edward Jaffe <[email protected]> > wrote: > > :>On 9/21/2012 5:01 AM, Peter Relson wrote: > :>> Of course Binyamin is right. Since the "runner" can get interrupted, then > :>> the runner needs to run within a transaction too. (Getting interrupted > :>> includes the z/OS LPAR getting interrupted by LPAR processing, which > :>> covers even the disabled PSW case) > > :>There are existing search/update models in which the "runner" performs its > :>search using only block-concurrent instructions (such as L) without > :>serialization and then checks later whether a retry is needed. A good > example is > :>IEANTRT. That code is FAST because the "retrieve" function never serializes > :>against the "update" function. > > Wonder how the delete works. Perhaps it leaves the storage orphaned? Otherwise > the scan, if interrupted, could be left with a link pointer to nowhere. > As Peter said,
On Sep 22, 2012, at 07:48, Peter Relson wrote: > > All such techniques that I know of rely on the fact that the blocks can > *never* be deleted. ... > IOW, they are removed from the active list and added to an idle list, not deleted. If the runner discovers (how?) that it has blundered into the idle list, it retries. The hazards include not merely interruptions, but concurrent operations on multiple CPUs. -- gil
