Help Requested on Arenas

[tristram at conan.esd.sgi.com]

In article <9007051819.AA09079 at trouble.cs.nps.navy.mil> zyda at trouble.cs.nps.navy.mil (michael zyda) writes:

   Help Needed with Using Arenas for Sharing Data Between Processes

	In order for the other processes to have access to that allocated
   shared memory, the other processes must somehow obtain a pointer
   to that allocated memory. How is this done safely, i.e. what
   system routine do I call in process 1 to find a pointer to
   the first byte allocated by usmalloc in process 2?

I'm pretty sure that if you specify all the parameters for the arena
identically in the two programs, and you call usinit() in the same
order (if you have more than one arena) both arenas will be mapped at
the same address.  The same is true of mapped files (since arenas are
built on mapped files, see mmap(2)).  So, one solution is to:

   1) map a small (1 or 2 K) file in both processes to serve as a
   rendezvous area.  You may specify the address at which the file is
   mapped or let the system do it for you.  It will be mapped at the
   same address in both processes.

   2) create the arena you need with usinit (in both processes)

   3) allocate from the arena in one process, and store the address
   somewhere in the rendezvous area.  You can create a struct that has
   some pointers in it to manage the rendezvous area.

   4) load the address from the rendezvous area into the other
   process, and access the data it points to in the arena.

You are still left with synchronization to do on your data accesses in
the arena.  You can allocate semaphores from the arena in the first
process, and store pointers to them in the rendezvous area.  

This still leaves you with a race on startup (if two programs both
think they are initializing the rendezvous area).  I suppose the
safest way is to have a single memory manager program which must be
running before any of your clients can run.  Or you can simulate
safety by hacking together something based on file locks.

--
--
David Tristram
tristram at sgi.com