On 11 November 2013 20:15, Jon Perryman <jperr...@pacbell.net> wrote:
>      L    R2,QUEUE
>      L    R3,NEXT_ENTRY
>     CS  R2,R3,QUEUE                    New queue head
> While this seems bullet proof, it's not. If there is a long delay between 
> between the L instructions then next entry could
> have been freed causing an abend.

If your code is referencing an item that may have been freed, then
your design is wrong.

> While the delay is very unlikely, it is still a possiblity (e.g. swapout 
> after first "L"). This example is just removing the first
> entry. If you try to remove an entry in the middle of the chain, you run a 
> larger risk.
>
> Some of the techniques we use to minimize risk:
> 1. Abend recovery
> 2. don't overload the entry - only contains shared information.
> 3. Place entry on a timeout queue before placing on a free queue or freeing.
> 4. Copy the entry to workarea - reduces reference time of actual entry
> 5. Eyecatchers that can be verified.
> 6. Unique identifier for each entry that can be verified.
> 7. Turn off interrupts.

Most of these are indicative of incorrect design rather than of
careful attention to risk. If it's unclear whether a queue entry is
eligible to be worked on or even to be looked at unless you do it in a
hurry, then there is something quite wrong.

By all means provide abend recovery, but don't make it part of the
queue handling design.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to