HP OpenVMS Systems

Memory Interlocking Granularity?

» close window

The Question is:

 
In a previous "Ask the Wizard" article (6984) the OpenVMS Wizard stated:
 
"The interlocked instructions can typically lock ranges of memory rather larger
 than the target bit (or target queue entry), ... thus bitlocks located near
 each other in virtual memory have unexpected contention. This contention will
 not disrupt the corre
ct opreration of the bitlocks, but it can slow the access to the bitlocks."
 
Can the Wizard elaborate on what "ranges of memory rather larger than the
 target bit (or target queue entry)" might mean?
 
I would for instance expect that __TESTBITSSI would "lock" the quadword
 containing the bit in question (and include "upto" the "aligned" quadword on
 either side assuming the bit in question is not in at least a quadword aligned
 memory location - the docum
entation does not state any alignment restrictions on the alignment of the
 "containing structure" for __TESTBITSSI).
 
If the memory location that contains the target of the operation in question
 meets some minimum alignment is it safe to assume that the memory of the
 (containing) structure itself is all that will be locked?
 
I seem to remember some bit of documentation stating that (each) global
 variable in a program is placed in its own PSECT by the linker. Hence given:
 
/* example.c */
unsigned long int SomeData;
unsigned long int MoreData;
 
void main(void) { }
/* end of example */
 
SomeData and MoreData end up in their own individual PSECTs (this seems to be
 confirmed by the MAP produced by the linker and in any event this could be
 forced via a #pragma).
 
Given the above example is it safe to assume that interlocked operations on
 SomeData (in its own PSECT) will not result in possible contention with
 MoreData (in its own PSECT)?
 

The Answer is :

 
  In regard to topic (6984), the granularity of memory affected by
  the hardware interlock is implementation-specific, and can involve
  anything from the smallest grain of memory (a longword) to all of
  system physical memory, and can also potentially be discontiguous.
 
  The particular psect allocation of variables depends on various
  factors, some under the control of the programmer and some not.
 
  It is not safe to make the proposed asumption, in other words.
 
  Topic (6984) has been updated.
 
  Please upgrade from OpenVMS V7.1-1H1 to a supported release.
 

  

     

     
answer written or last revised on ( 4-JAN-2002 )
     
» close window