Typically an application allocates shared memory, and then calls fork()
to create 1 or more child processes which then are able to share that
shared memory segment.  I have a requirement for non sibling processes
which need to share items in shared memory. I am not familiar with any
solutions in this area. Below is a very brief outline of my approach,
I would greatly appreciate pointers to existing work or discussion about
my approach.

- Maintain a "catalog" of items and the shared memory ID that the items
  are stored in.

- Operations on the catalog are as follows:
  - add item
  - delete item
  - query items in catalog
  - request a read/write lock to an item
  - request a read only lock to an item
  - release a lock
  - initialize / terminate

- I realize I could have a client/server or client side only approach.
  Currently, I am leaning toward a client side only solution where I maintain
  the catalog in shared memory, with 1 semaphore that controls access to
  the catalog data (it provides the necessary locking for adds/deletes...).

- The first process up would actually initialize the empty catalog, others
 would simply connect to it, and execute transactions.

- For the most part, the access patterns will be very low-bandwidth, e.g.
  a process comes up, requests data is shared memory, and then releases
  that data upon it termination -- I realize that the single semaphore
  would be a major bottle neck if a process was locking/unlocking... with
  a high frequency.

If you have seen work in this area, please let me know.

Thanks,

-----------
John Love,                 jl...@lgc.com
Landmark Graphics          Houston, TX
(713) 579-4683