Problem with sharing data by an installed shareable image

[P R Stone]

I am trying to pass data between processes using a shared data area. Prog 1 will initialise the data and subsequently instances of Prog2 will access the data without the overhead of the initialise time.

To prototype this I have tried to use the SW_SHR example refered to in the cookbook. I have adjusted sw.cxx and sw.hxx to define arrays to hold the initialised data.

public
int setstring(char *p);
int getstring(char *p);
char public_buffer[1024];

private
char private_buffer[1024];

When the class is instanciated (on install or running of PROG1?) I would hope to be able to access the public_buffer by PROG2 (or the private buffer via the getter and setter).

Unfortunately when I do this I can set the data and examine it with PROG1 but PROG2 seems to have its own instance of the class and hence its own data.

Is the problem in my linking and installing or have I misinterpretted the way this works?

Notes
-----
the symbol_vector is
SYMBOL_VECTOR=( -
SW_G_SW = DATA, -
SW_REAL__9STOPWATCHXV = PROCEDURE, -
SW_RESET__9STOPWATCHXV = PROCEDURE, -
SW_INIT__9STOPWATCHXV = PROCEDURE, -
SW_START__9STOPWATCHXV = PROCEDURE, -
SW_STOP__9STOPWATCHXV = PROCEDURE, -
SW_GETSTRING__9STOPWATCHXPC = PROCEDURE, -
SW_SETSTRING__9STOPWATCHXPC = PROCEDURE, -
SW_SYSTEM__9STOPWATCHXV = PROCEDURE, -
SW_USER__9STOPWATCHXV = PROCEDURE, -
SW___CT__9STOPWATCHXV = PROCEDURE)

SW_VEC_ALPHA.MAR now contains
.PSECT $$SW_VECTOR PIC, OVR, REL, GBL, SHR, -
NOEXE, WRT, QUAD

I install using
INSTALL CREATE/SHARE/WRITE my_disk:[my_dir]SW_SHR.EXE

I run using
- login A
DEFINE sw_shr my_disk:[my_dir]SW_SHR.EXE
run PROG1

Status = 1 G_sw: = 1
SYSTEM CPU time = 0 G_sw: = 0
User CPU time = 0 G_sw: = 0
Real time = 0 G_sw: = 0
Resolution = 0.01 G_sw: = 0.01

Private Buffer = PRIVATE G_sw: = PRIVATE

Public Buffer = PUBLIC G_sw: = PUBLIC

wait for input

- login B (same use id)
DEFINE sw_shr my_disk:[my_dir]SW_SHR.EXE
run PROG2

Status = 1 G_sw: = 1
SYSTEM CPU time = 0 G_sw: = 0
User CPU time = 0 G_sw: = 0
Real time = 0 G_sw: = 0
Resolution = 0.01 G_sw: = 0.01

Private Buffer = G_sw: =

Public Buffer = G_sw: =

I was using C++ as I was hoping to use the Standard library to give me hash access to the data. ie if I could have a multiset it would be perfect.

[Hein van den Heuvel]

File backed, shared data has its purpose but often is messy to deal with. And with all the linking option to deal with, I woudl look for alternatives.
I'd recommend reading up on the SYS$CRMPSC system service and it's friends.

It compares to the SHMGET/SHMAT Unix calls.

It just return a base address for the shared memory to use.

You can control access through a lock, or just use the 'SS$_CREATED' status to learn that you are the first and need to initialize. If the init is slow, you may need a secondary interlock, or at least a 'initialized' flag to wait for.


Good luck,
Hein.

[Hein van den Heuvel · Accepted solution]

Besides the symbol_table stuff, what is used in the linker .opt file for creating SW_SHR?

C++ does (naming) stuff a little different, but I am pretty sure that you needed something like:

psect_attr=public_buffer_psect,shr


You might want to turn the test around.
If you do not INSTALL /SHARE/WRITE SW_SHR then do you get:

%DCL-W-ACTIMAGE, error activating image PROG1
-CLI-E-IMGNAME, image file SW_SHR
-SYSTEM-F-NOTINSTALL, writable shareable images must be installed

You should get that if it is truly a write shareable image. If not, check out the psect attributes create and study the /map files on the link (LINK/MAP/FULL/CROSS [/SHARE])

Hein.

[John Donovan_4]

We do this all the time here in FORTRAN. As Hein pointed out, our option file has the following entries:
my_full_image_spec/shareable
psect_attr=common_image_name,shr

We also use memory mailboxes quit a bit, but thats more of a FIFO cycle.

[John Gillings]

Once you've identified the PSECT contining your data, setting it to GBL,SHR,WRT should give you a writeable shareable image.

That said, I would strongly recommend AGAINST exporting any "naked" data from a shareable image. Instead, create procedural interface to read and write the data. You can still have the same shareable, writeable PSECT, but it's hidden inside the image. The only way to touch it is by calling routines.

There are several reasons for this.

All accesses to shareable data MUST be synchronized. If the data itself is exported, you are trusting all the code that references it to do the right thing.

With a procedural interface you can enforce, and hide, the synchronization mechanism inside the shareable image. That leaves you free to change the mechanism if a more appropriate, or faster one is found, or you need to extend the scope (process, CPU, cluster node, network).

Similarly, you can easily change the layout or implementation of the data without affecting clients. So, for instance, you could start by implementing the shared storage as an RMS file. That might be slow, but it's easy to get right. Once you've got the prototype debugged and tested, then worry about making the shared writeable memory stuff working. Consider, what if the next generation of CPUs want data to be OCTAWORD aligned, instead of LONG or QUAD? Easy to fix with a hidden data structure, IMPOSSIBLE otherwise without finding nd revising every piece of client code.

You could also add an interface that accesses the same storage via a network connection. Client programs see exactly the same interface. All the mesy details of access and synchronization are hidden.

Exposed, naked data structures force you to set too many decisions in concrete and severely limit your options for future improvements.

Please think VERY carefully before putting any DATA entries in your symbol vectors!

[Bruce Visscher_1]

> I was using C++ as I was hoping to use the
> Standard library to give me hash access to
> the data. ie if I could have a multiset it
> would be perfect.

Trying to locate a standard container (multiset or anything else) in shareable memory on OpenVMS (or perhaps any O.S.) is not going to be trivial. The standard does provide the ability to override the standard allocator for precisely this kind of thing but to use it you would have to implement a special heap to be able to take advantage of this. I think it is doable, but something to think about.

Good luck.

[P R Stone]

I have found a way forward.

I added the following line to the SW_SHR_ALPHA.OPT
SYMBOL_VECTOR=( -
.......
XBUFFER = DATA)
PSECT_ATTR=XBUFFER,SHR

In sw.hxx I added the following (outside the class definition)

char xbuffer[1024];

I can now write programs PROG1 and PROG2 to update and access xbuffer.

This is not quite what I wanted but sort of solves the problem (I think).
The plan is to allow the class to initialise itself and once complete will serialise itself (data only) into the data area xbuffer.
Subsequent calls to the class will deserialize xbuffer into the class variables.
Since the initialise is doing all the file access and if the deserialize is quick then there should be the improvement I am hoping for.

Notes -
The class methods will provide all access to the data in xbuffer and I can use event flags and a version stamp in xbuffer to enforce synchronisation.

I am not using sys$crmpsc as the shared image
can be installed rather than having a process
maintain it.