howie@voodoo.voodoo.uucp (howie) (12/19/90)
Here's a question for someone with experience with shared memory (and malloc). I have a pointer in a segment, shared by two processes. If one of the processes does a malloc() using that pointer, will the other process have access to that portion of memory that has been malloced. Thanks for any help. -- howie uunet!bcstec!voodoo!howie
hunt@dg-rtp.rtp.dg.com (Greg Hunt) (12/19/90)
In article <647@voodoo.UUCP>, howie@voodoo.voodoo.uucp (howie) writes: > > Here's a question for someone with experience with shared memory (and > malloc). > > I have a pointer in a segment, shared by two processes. If one of the > processes does a malloc() using that pointer, will the other process have > access to that portion of memory that has been malloced. No, I'm afraid not. The malloc() call allocates unshared space from the calling process's stack or heap. That memory can only be used by the calling process itself, the other processes cannot see that memory since it's not in their process. To do what you want, you have to set aside a portion of the shared memory segment that both processes share as a shared "heap", and write your own routines to parcel out that shared memory. This means you need to write your own versions of malloc() and free() that operate on shared memory (call them something else to avoid interfering with the standard malloc() and free()). If that sounds too complex to you, I'd suggest that you set aside portions of the shared memory segment when you initially set it up that are the right sizes for what you need. Then have one of the processes compute and store the pointers to the areas before either of them want to use the areas. This will give you "static" areas that you can use. Remember that using pointers in shared memory segments assumes that all of the processes attach the segment at the same virtual address in their address spaces. If you don't ensure this, then the pointers will point to different places, and that'll surely mess things up. I always use offsets from the beginning the segment and compute the pointers I need by adding the offset to the attach address in this process. If I need to access the pointers often, I'll save them in global pointers and compute them just once. This avoids the problems caused by different processes attaching the shared memory to different addresses in their process space. Shared memory can be used to solve lots of problems, but sometimes it's not easy to set it up the right way. Good luck. -- Greg Hunt Internet: hunt@dg-rtp.rtp.dg.com DG/UX Kernel Development UUCP: {world}!mcnc!rti!dg-rtp!hunt Data General Corporation Research Triangle Park, NC, USA These opinions are mine, not DG's.
caxwgk@pkinbg.UUCP (Wolfgang Kuehnel ) (01/14/91)
From article <1990Dec19.144959.16561@dg-rtp.dg.com>, by hunt@dg-rtp.rtp.dg.com (Greg Hunt): > In article <647@voodoo.UUCP>, howie@voodoo.voodoo.uucp (howie) writes: >> >> Here's a question for someone with experience with shared memory (and >> malloc). >> >> I have a pointer in a segment, shared by two processes. If one of the >> processes does a malloc() using that pointer, will the other process have >> access to that portion of memory that has been malloced. > > No, I'm afraid not. The malloc() call allocates unshared space > from the calling process's stack or heap. That memory can only be > used by the calling process itself, the other processes cannot see > that memory since it's not in their process. > > To do what you want, you have to set aside a portion of the shared > memory segment that both processes share as a shared "heap", and > write your own routines to parcel out that shared memory. This > means you need to write your own versions of malloc() and free() > that operate on shared memory (call them something else to avoid > interfering with the standard malloc() and free()). I've once written a set of routines that manage the above problem. They create a SHM of a given size and attach the process to the SHM. Identi- fication of the SHM is done by a file read by all involved processes. The are routines to shm_alloc() , shm_realloc(), shm_free() the amount of memory created by shm_init(). So a process can alloc() a portion of the SHM. The data in this part of the SHM can be accessed by other processes when the exchange information about where the data starts. So there has to be some additional application specific mechanism to "broadcast" the adresses of the malloc-ed memeory. The shm_malloc() and shm_free() routines are based on the malloc() and free() routines published in chapter eight of Kernighan-Ritchies basic book on the C language. The difference is that a limited amount of memory is handled, there is no sbrk() for SHM. You can alter the functions yourself, (beware of a bug in K+R free()- function, at least in the german translation) or I can post the stuff. Possibly on Friday. Wolfgang
gwyn@smoke.brl.mil (Doug Gwyn) (01/15/91)
In article <943@scaxs2.pkinbg.uucp> caxwgk@pkinbg.UUCP (Wolfgang Kuehnel ) writes: >beware of a bug in K+R free()-function, at least in the german translation There were no bugs in the malloc()/free() implementation in the second edition of K&R, at least not as of the time when I reviewed the draft. However, there were a few subtleties.
gwyn@smoke.brl.mil (Doug Gwyn) (02/01/91)
In article <951@scaxs2.pkinbg.uucp> caxwgk@pkinbg.UUCP (Wolfgang Kuehnel ) writes: -From article <14854@smoke.brl.mil>, by gwyn@smoke.brl.mil (Doug Gwyn): -> In article <943@scaxs2.pkinbg.uucp> caxwgk@pkinbg.UUCP (Wolfgang Kuehnel ) writes: ->>beware of a bug in K+R free()-function, at least in the german translation -> There were no bugs in the malloc()/free() implementation in the second -> edition of K&R, at least not as of the time when I reviewed the draft. -> However, there were a few subtleties. -void free(ap) -char *ap; -{ -register header *p,*q; - - p = (header *)ap; - p = p - 1; /* auf Beschreibung zeigen */ - for (q=allocp;!(p>q && p<q->s.ptr);q=q->s.ptr) - /* Das ^ ist ein "-" in Kernighan/Ritchie */ -The '=' marked above is printed '-' in K+R of Hanser Verlag in Germany. ... -That's not a subtlety, I think. That appears to be a MODIFIED version of the code from K&R 1st Edition; I have no idea who modified the code or why, but the bug does not appear in the second printing of the 1st Edition nor in the (corresponding but substantially different) code in the first printing of the 2nd Edition.