On Apr 17, 2011, at 03:04, Andy Coburn wrote: > > I've never be overly fond of specifying SMC=STEP on an ENQ macro. Seems > dangerous. But even with SMC, if there is any way whatsoever that the > routine in question can be interrupted (excluding abends caused by program > errors which would be fixed during development) then an interruption caused > by (say) a TSO user logging off, will cause one's ESTAEX or ARR recovery > routine to be entered. > > If the interruption occurred while the list was partially updated, and if > the ESTAEX recovery routine attempts RETRY, the chain pointers will be > corrupt and unless the ESTAEX recovery routine can (with 100% certainty) > restore the chains to their original state the corruption will manifest > itself later. > In order that processes merely reading the list not perceive a corrupt state, readers must issue an ENQ SHR on the same resource on which updaters issue an ENQ EXC. Is this not sufficient?
Name/token services uses a protocol where readers needn't lock. This was described in IBM-MAIN a few years ago. It involves a counter incremented by updaters (which do lock against each other) and a design such that dangling pointers do not cause misbehavior of readers (following a pointer from an entry in the free list will not result in a loop). I can no longer reconstruct it it mentally; I need to review it. -- gil
