Return to BSD News archive
Xref: sserve comp.unix.programmer:11468 comp.unix.bsd:12523 Newsgroups: comp.unix.programmer,comp.unix.bsd Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!noc.near.net!analog.com!analog.com!nwd2sun2.analog.com!Mike.Long From: Mike.Long@analog.com (Michael W. Long) Subject: Re: mmap for shared memory, how to use efficiently? In-Reply-To: muts@compi.hobby.nl's message of Wed, 1 Sep 1993 21:16:24 GMT Message-ID: <MIKE.LONG.93Sep2173535@cthulhu.analog.com> Sender: usenet@analog.com Reply-To: Mike Long <Mike.Long@Analog.com> Organization: Analog Devices Inc, Norwood MA, USA References: <MUTS.93Sep1221625@compi.hobby.nl> Date: Thu, 2 Sep 1993 22:35:35 GMT Lines: 44 >>>> On Wed, 1 Sep 1993 21:16:24 GMT, muts@compi.hobby.nl (Peter Mutsaers) said: >> I want to use mmap to get some memory at a specific memory location >> (where some global variables exist). It must be shared between 2 >> processes. >> I can use a normal file as the shared object, like /tmp/mmap_file. But >> in that case, the speed is quite low because operations seem to update >> the real file immediately, therefore the shared memory speed is as low >> as the disk speed. >> Can someone help me and tell what the normal/best way is to use mmap; >> is it possible to open /dev/mem or something like that and then use >> that as shared object, or is there another device that will not cause >> disk IO but still be accessible between 2 or more processes? You can use mmap(2) for this application without the overhead of disk I/O by using either /dev/null or /dev/zero (if present) as the file to map. Using mmap on /dev/zero has the nice side effect of initializing the shared memory segment to all zeros. Note that segments created using mmap can only be shared by the process that calls mmap and any children it subsequently forks. Also, for any shared memory application a means of guaranteeing exclusive access to the shared segment must be used to prevent evil concurrency problems. Your best bet for that would be the System V semaphore mechanism, accessed through semget(2), semop(2), and semctl(2). You may be better off using the System V shared memory as well, using the calls shmget(2), shmat(2), shmdt(2), and shmctl(2). If you use shmget et. al., you can't really tell the system where to map the memory. Your best bet is to define a structure containing all of the variables you need to share, and accessing that structure through a global pointer. An advantage that shmget et. al. have is that the processes that share the memory segment do not have to descend from a common parent. System V IPC requires keys to distinguish different shared memory segments, semaphores, etc. You may also want to look at ftok(3) for a way to generate them. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer voice: (617)461-4030 Analog Devices, SPD Div. FAX: (617)461-3010 Norwood, MA 02062 My opinions are mine mine MINE!!!