HP OpenVMS Systems

Shared memory programming? ($updsec)

» close window

The Question is:

 
I am working with $CRMPSC and related services and seem to be a bit confused as
 to what's going on. I am attempting to create a system global section which is
 backed by the pagefile.
 
If I run my "proof of concept" in two different sessions under the debugger I
 can see the data changing (in the other process).
 
If I then call $UPDSECW to write the global section out $UPDSEC returns
 SS$_NOTMODIFIED at both the return value and in the IOSB.
 
Why am I seeing SS$_NOTMODIFIED as the return value when I have obviously (at
 least I think I have) changed data in the section and observed the changed
 data in another process which has the section mapped (by running the same
 program). Am I misunderstand
ing the use of $UPDSEC when a section is pagefile backed?
 
The example I have been playing with follows. Error checking and anything
 unnecessary has been removed. The example has only been tested on OpenVMS 7.3.
 
 
#include <descrip.h>
#include <efndef.h>
#include <lib$routines.h>
#include <psldef.h>
#include <secdef.h>
#include <starlet.h>
#include <syidef.h>
 
#include <string.h>
 
typedef struct {
   int  status;
   int  unused;
} IOSB;
 
void main(void) {
 
   IOSB  iosb;
   int   status;
 
   $DESCRIPTOR(SecDsc, "XferData");
 
   int  inadr[ ]    = { 0x200, 0x200 },
        mapadr[2],
        retadr[2];
 
   int  flags       = SEC$M_GBL | SEC$M_DZRO | SEC$M_EXPREG | SEC$M_WRT |
                      SEC$M_SYSGBL | SEC$M_PAGFIL;
 
   status = sys$crmpsc(&inadr,          /* inadr.r              */
                       &retadr,         /* retadr.r             */
                       PSL$C_USER,      /* acmode.v             */
                       flags,           /* flags.v              */
                       &SecDsc,         /* gsdnam.d             */
                       0,               /* ident.r              */
                       0,               /* relpag.v             */
                       0,               /* chan.v               */
                       32,              /* pagcnt.v             */
                       0,               /* vbn.v                */
                       0,               /* prot.v               */
                       32);             /* pfc.v                */
 
   int  *ptr = (int *) retadr[0];
 
   for (int i = 1; i < 2048; ptr++, i++)
      *ptr = 0xaabbccdd;
 
   status = sys$updsecw(&retadr, &mapadr, PSL$C_USER, 0, EFN$C_ENF, &iosb, 0, 0);
 
 
 

The Answer is :

 
  The sys$updsec and sys$updsecw services are intended to write the pages
  that the calling process has modified out to the backing storage file.
  (Key here is that the information on modified pages is process-local.)
 
 NOTMODIFIED,  no pages in the section were modified
 
  Facility:     SYSTEM, System Services
 
  Explanation:  The update request completed successfully without queuing any
                I/O requests because no pages in the input address range had
                been modified. The operating system does not normally display
                this message; the user program should be able to detect and
                respond to the condition.
 
  User Action:  None.
 
  When a section is backed by a page file, the data is considered volatile.
  The data itself arguably resides in system virtual memory, and will vanish
  when there are no processes mapped to the section file.  (The page file
  is used to permit the paging of the memory associated with larger sections,
  and not to provide the ability to survive system or application restarts.)
  If you wish your data to survive process rundowns or system restarts, you
  should use a section that is backed by an application section file.
 
  Topic (1661) contains a list of some of the more common programming
  errors, and contains pointers to topics on correctly accessing shared
  memory and on correct interactions with the memory caches.  In addition
  to (1661), topics (6984) and (7383) will be of interest here, as will
  (2681) and (2486).
 

  

     

     
answer written or last revised on ( 6-MAY-2002 )
     
» close window