Could you provide an insight to a design that would handle the situation where 
an SSI program with non-trivial workload uses a very large list. This list is 
normally semi-static but there can be periods of time where entries are heavily 
deleted and added. Not freeing storage is an option because it could be a 
significant amount of storage. 

Thanks, Jon Perryman.



>________________________________
> From: Tony Harminc <[email protected]>
>To: [email protected] 
>Sent: Monday, November 11, 2013 7:07 PM
>Subject: Re: Serialization without Enque
> 
>
>On 11 November 2013 20:15, Jon Perryman <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
>
>
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to