 |
The Question is:
We are having problems two very large c programs and getting them to talk to
each other.
The two processes read to and write from an area of shared memory.
The processes need to synchronise before a write or read and do this by
writing a request into a separate area of the same shared page. It then
sets a waiting flag to true which is also another area of the same shared
page. It then uses the sys$hiber()
call to wait for the other process to synchronise. If the waiting flag for
the other process is set these steps will be ignored. The other process
checks for any requests in the communication area of shared memory every
cycle. If a request is there it w
ill run until the time specified in the request is reached, then it will
wake the other process using the sys$wake call.
The lagging process which picks up the requests is crashing in random places
and we have found that it is setting its waiting flag to true when the code
to do this is not even executed. A stack overflow problem is therefore very
likely. However we have
checked the synchronisation is working properly, There are no shared event
flags. We have tried increasing the stack size at link time and increasing
the quotas.
Since the shared memory area is in p0 space, is it possible that with such a
big program that the shared memory page and the program are overlapping?
The Answer is :
Writing information into shared memory requires correct application
synchronization, as discussed in topics 1661 and 2681 in detail.
Topic 1661 also details a variety of common programming bugs.
sys$hiber is not centrally intended as a synchronization tool, and
applications using it are required to manage any spurious wakeup
requests that can and do arise. (As referenced in topic 1661.) A
periodic call to sys$wake (or sys$schdwk) is often useful in an
application using sys$hiber -- deliberately creating a spurious
wakeup -- as it can help drain pending activity if a sys$wake call
is missed.
A simple example of using shared memory from C is posted at the
OpenVMS Ask The Wizard area.
Care must be taken when operating in a multiprocessing environment,
as the behaviour of the processor memory caches must be considered
when accessing memory. On OpenVMS Alpha, this includes the use of
memory barriers and interlocked operations as required -- see topic
2681 for details.
Access to shared memory should generally be consolidated into as
few routines as possible, and then integrated into a shareable image
or similar -- this approach permits easier debugging and better control
over the shared memory accesses. (Details of the creation and use of
shareable images are available at the Ask The Wizard website.) This
approach also eases the introduction of logging and debugging support
into the application environment, as well as providing a way to
add a condition handler for errors related to the shared memory,
as well as easing the application-specific upgrade path(s) available
to the programmer(s).
As for your question on memory overlaps -- and since rogue pointers
are certainly one possible cause -- yes. That said, as pages of
memory containing executable code and constants are protected (by
default) against any write access, this is unlikely.
The most common causes of these problems tend to involve memory
pool (heap) corruptions, writing too much to a variable on the
stack (thus corrupting the stack), and writing to a variable that
is no longer in an active stack frame. See 1661 for a rather more
lengthy discussion of potential problems.
|
|
|
|
|
