The Question is:
Interlocked instructions, secondary-interlock, retries count
esp. as related to the __PAL_INSQ* C builtins
the documentation comments, that after some number
of retries, assume your queue is corrupted.
1. What might be a reasonable value of "some number of retries"?
f'instance, in VMS itself, what's typical/worst-case for
retry count. are there any rules of thumb?
2. Is it true that a "secondary interlock" failure
should (normally) only be seen on a system
running multiple processors?
The Answer is :
unknown and false, respectively.
You probably should not need to retry the operation, but there could
be circumstances where a retry count value as high as 1000 might be
appropriate. The OpenVMS Wizard would prefer to go try some other
activity (randomized back-off, etc), then come back later for another
attempt at the queue operation.
The interlocked queue instructions use a hardware memory interlock first,
while updating the secondary interlock, and then release the memory
management lock. This involves communications across all processors
and all caches that might be present in the SMP system. The use of the
secondary interlock is to avoid the cost of the interprocessor
communications and the cache invalidation operation. But most any
errant code could quite conceivably drop some crud onto that bit...