 |
The Question is:
When is data in a sharable image that's installed as writable written to disk?
I've written a small program that links to a
very simple shareable image that's installed as writable. Does a write to the
sharable remain
in memory until some significant condition is met to force the new data to be
flushed to the sharable image file on disk? Is there any VMS command that
allows me to monitor disk I/O on the shareable image file?
The Answer is :
In short, no. You cannot control when data is written, what order it is
written or monitor when it occurs. Shareable image writable data is
managed by the virtual memory paging mechanism, so there is no direct
means for controlling or observing its behaviour. Indeed, OpenVMS does
its very best to avoid writing the data out to disk -- caching data in
host memory (for reasons performance) is a goal of the OpenVMS virtual
memory management subsystem.
If you terminate all processes that have mapped the shareable image,
and uninstall the image, then OpenVMS will (eventually) flush the
underlying global section(s) out to disk.
Writable global sections can be very fast, but one of the costs of
that speed is loss of direct control of the data. If you need that
level of control, then don't use a writable shareable image. Instead,
you should create a writable section yourself ($CRMPSC) and request
updates when required ($UPDSECW). But note that this is potentially
an expensive operation, as it involves selective flushing of the
modified page list by SWAPPER.
Again, this is a speed/control tradeoff. If you were to implement
complete control over the time and sequence of updates to disk, you
would find your code would be no faster (and probably much slower) than
using RMS files with global buffers - since that is essentially what
RMS does for you!
The OpenVMS Wizard strongly discourages the use of writable shareable
images. Why? While these are and can certainly be functional, this
coding technique often leads to maintenance and support and upgrade
problems -- position-dependent constructs tend to be far more difficult
to support than position-independent constructs. The OpenVMS Wizard
would strongly encourage the use of RMS Global Buffers or of global
sections -- and would particularly encourage using position-independent
coding constructs. Details of global sections and of example code are
available at the Ask The Wizard area. Yet easier and cluster-capable
is the RMS global buffer mechanism -- RMS global buffers provide
cluster-wide data coherency, and performance. (By the time you write
and debug your application -- and deal with the cache coherency and
interlocking -- you might have been better off with RMS or middleware.)
For various related coherency and caching and interlocking discussions,
please see Ask The Wizard topics (1661), (2681), (6984) and (7383).
|
|
|
|
|
