Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!uwm.edu!bionet!ames!sgi!shinobu!odin!odin.corp.sgi.com!tristram From: tristram@conan.esd.sgi.com Newsgroups: comp.sys.sgi Subject: Re: Help Requested on Arenas Message-ID: Date: 9 Jul 90 13:44:49 GMT References: <9007051819.AA09079@trouble.cs.nps.navy.mil> Sender: news@odin.corp.sgi.com Organization: Lines: 44 In-reply-to: zyda@trouble.cs.nps.navy.mil's message of 5 Jul 90 18:19:45 GMT In article <9007051819.AA09079@trouble.cs.nps.navy.mil> zyda@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@sgi.com