On Sep 26, 2012, at 18:33, Robert A. Rosenberg wrote: > At 13:42 +0000 on 09/24/2012, David Stokes wrote about Re: The > Transaction state (was Model 2827 New Instructions): > >> Yes, when I read "what happens when a parallel task deletes my data >> while I'm using it", I think, maybe better not to allow that to >> happen. The whole list might have been logically deleted "behind >> you" amongst many other possibilities, and it doesn't need an >> interrupt. So I offered my suggestion that one typically needs to >> serialize over the whole process until one has "used" the data in >> such a case. Or avoid such a situation, e.g. by marking an object >> in-use/free or whatever (which will still need serialization, of >> course). But obviously pointless for me to pursue the matter, >> interesting as it is. > > If your serialization is being done via an ENQ, you run into the > issue that ENQ is BAD (Broken As Designed) since while it will allow > a user who has a SHR ENQ to upgrade it to EXC (the purpose of which I > wonder about since there might be other SHR owners who will prevent > you from getting the EXC unless this request puts you into a wait > state like doing the EXC request and also waiting any SHR requests > issued after you until all the current SHR owners DEQ) there is no > way an EXC owner can keep the ENQ but downgrade it to SHR. This > downgrade should be simple to do since all that is required is to > switch the EXC status to SHR (leaving the task as the first entry on > the ENQ chain) and THEN run the DEQ routine that runs the queue > releasing all tasks in "waiting for SHR" status until you hit the end > of the queue or hit a "waiting to get EXC" entry.
Peter Relson contradicted himself in this thread, likely through haste. With my meager knowledge, I suspect he was right the first time. Ed J., with far deeper knowledge than I appears to concur with that. The reader needn't serialize provided the design assures: o Nodes once used are never discarded; they are kept as inactive. o No catastrophe such as Protection Exception or endless loop occurs if the reader wanders into inactive nodes. o The reader can and does detect possibly invalid results and retries. Your stump speech about downgrading ENQ is a different topic, although one with which I heartily agree. -- gil
