Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!ritcv!cci632!crp From: crp@cci632.UUCP Newsgroups: comp.unix.wizards Subject: Re: Motorola shared memory questions Message-ID: <2581@cci632.UUCP> Date: Thu, 3-Dec-87 13:52:58 EST Article-I.D.: cci632.2581 Posted: Thu Dec 3 13:52:58 1987 Date-Received: Sun, 6-Dec-87 17:21:16 EST References: <106600017@datacube> <106600019@datacube> Organization: CCI, Communications Systems Division, Rochester, NY Lines: 52 Summary: Be wary of the direction of the "next" segment ... In article <106600019@datacube>, ftw@datacube.UUCP writes: > > When I call shmat() for the first time, use a NULL arg. for the attach > address; shmat() gives out virtual addresses that are always (shared memory) > block aligned, even if the corresponding shmat() asked for a smaller chunk > of memory. > > Successive calls to shmat() should have an arg of whatever the first shmat() > returned for the virtual address, plus the number of bytes requested so far. ^^^^ Be warned that some implementations allocate segments like this (i.e. progressively higher addresses), while others allocate segments from higher to lower addresses. In which case, the virtual address of the second and subsequent segments the address of the previous segment *minus* the *size* of that segment. Note that in this scenario, the address of the contiguous memory is actually the address of the *last* segment allocated; while with progressive addresses it's the address of the *first* segment. In any case, you should always attach any partial segment required last (i.e. size_of_all_shared_memory % segment_size), so that all segments are properly aligned. For example, to attach 600,000 bytes of shared memory on a machine with 128K segments and progressive addresses: start = attach 128K segment at first available address nextaddr = start + 128K nextaddr = attach 128K segment at nextaddr nextaddr += 128K nextaddr = attach 128K segment at nextaddr nextaddr += 128K nextaddr = attach 128K segment at nextaddr nextaddr += 128K nextaddr = attach 88000 byte segment at nextaddr return(start) > This ensures a nice, flat virtual address space. > > Jonathan Creighton (pyrnj!oracle!jcreight) has an interesting suggestion: > he suggests that I choose a virtual address that is closer to the midpoint > between the current stack and heap, so that I won't run out of space for > malloc() or lotsa nested funtion calls. Also be warned that dynamic stack growth or heap growth can trash (or detach) shared memory in certain implementations. You'll have to test your own configurations to learn this. An easy way out of problems like this is to pre-allocate stack and heap by calling an initialization function with *lots* of local variables (to grow the stack) and then malloc(lots_of_mem). Chuck Privitera (... !rochester!cci632!crp) Computer Consoles Inc. Rochester, New York variable