  Transient application failures? 
 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.
 
