HP OpenVMS Systems

Interlocked PAL calls and retries?

» close window

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?
 
thanks.
 
 
 

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...
 

  

     

     
answer written or last revised on ( 21-JUL-2000 )
     
» close window