On Sep 22, 2012, at 07:48, Peter Relson wrote: >> 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. > > All such techniques that I know of rely on the fact that the blocks can > *never* be deleted. With transactions, you can accommodate deletion. > > This is true for name/token and even CPOOL (which doesn't even need to > "run" just look at the first element's forward pointer). > I recall there was a discussion in IBM-MAIN where an expert (you? Jim Mulder? John Eells?) explained the IEANT* technique. I'd like to refresh my memory, but I can't find any good keywords for the archive search (always too many hits, or irrelevant).
Can someone suggest a good keyword set? IIRC, it involved a non-overflowing that the updater incremented (when?) and the runner fetched before and verified after. But I can't reconstruct what prevents failure if the runner fetches too late or verifies too early. Two counters? Leading and lagging? Thanks, gil
