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.
