[Info-vax] Returning data from Cobol AST routine.

[Stephen Hoffman]

On 2021-09-30 01:01:44 +0000, Andrew Commons said:

> On Thursday, 30 September 2021 at 2:48:15 am UTC+9:30, Stephen Hoffman wrote:
>> On 2021-09-29 09:12:20 +0000, Andrew Commons said:
> 
>> INSQUE and REMQUE are interruptable. Best use equivalent the 
>> interlocked queue operations INSQ*I and REMQ*I. Which are not.
>> 
> The distinction between the instructions is the type of queue they handle.
> 
> From the manual:
> 
> "Both INSQUE and REMQUE are implemented as noninterruptible instructions."

Yeah, you're right. INSQUE and REMQUE are non-interruptible within the 
context of a single processor. But they're concurrent within the 
context of a multiprocessor. And with no visibility within the 
multiprocessor memory caching. Which in aggregate leads to some 
hard-to-debug surprises.

See chapters 5 and 6 for a start:
    https://vmssoftware.com/docs/VSI_PROGRAM_CONCEPTS_VOL_I.pdf

Also scrounge up a copy of EL-00032-00 DEC Standard 32, and see section 
3.8 (page 3-95ff) and chapter 7 (e.g. section 7.1.4, using interlocks 
to prevent the corruption of shared data ):
    
http://www.bitsavers.org/pdf/dec/vax/archSpec/EL-00032-00-decStd32_Jan90.pdf 


If your app code stays strictly on one processor and forever avoids 
concurrent access to the structures within an SMP system, you can get 
away with INSQUE and REMQUE.

Just as soon as the queue becomes shared across processors (KP threads, 
multiprocessing), not so much.

I've chased enough of these sync bugs over the years that I'll usually 
avoid REMQUE and INSQUE in preference for using INSQHI, INSQTI, REMQHI, 
REMQTI, etc.

Another advantage of using INSQHI, INSQTI, REMQHI, REMQTI, etc, is 
relative addressing, which means any process or global sections 
involved can be mapped at different address ranges in different 
processes. Which is really handy.



-- 
Pure Personal Opinion | HoffmanLabs LLC