(ipc.info.gz) Notes

 
 1.8 Miscellaneous Notes
 =======================
 
 The system calls are mapped into one - `sys_ipc'. This should be
 transparent to the user.
 
 1.8.1 Semaphore `undo' requests
 -------------------------------
 
 There is one sem_undo structure associated with a process for each
 semaphore which was altered (with an undo request) by the process.
 `sem_undo' structures are freed only when the process exits.
 
    One major cause for unhappiness with the undo mechanism is that it
 does not fit in with the notion of having an atomic set of operations
 on an array. The undo requests for an array and each semaphore therein
 may have been accumulated over many `semop' calls. Thus use the undo
 mechanism with private semaphores only.
 
    Should the process sleep in `exit' or should all undo operations be
 applied with the IPC_NOWAIT flag in effect?  Currently  those undo
 operations which go through immediately are applied and those that
 require a wait are ignored silently.
 
 1.8.2 Shared memory, `malloc' and the `brk'.
 --------------------------------------------
 
 Note that since this section was written the implementation was changed
 so that non-specific attaches are done in the region 1G - 1.5G. However
 much of the following is still worth thinking about so I left it in.
 
    On many systems, the shared memory is allocated in a special region
 of the address space ... way up somewhere. As mentioned earlier, this
 implementation attaches shared segments at the lowest possible address.
 Thus if you plan to use `malloc', it is wise to malloc a large space
 and then proceed to attach the shared segments. This way malloc sets
 the brk sufficiently above the region it will use.
 
    Alternatively you can use `sbrk' to adjust the `brk' value as you
 make shared memory attaches. The implementation is not very smart about
 selecting attach addresses. Using the system default addresses will
 result in fragmentation if detaches do not occur in the reverse
 sequence as attaches.
 
    Taking control of the matter is probably best. The rule applied is
 that attaches are allowed in unmapped regions other than in the text
 space (see <a.out.h>). Also remember that attach addresses and segment
 sizes are multiples of PAGE_SIZE.
 
    One more trap (I quote Bruno on this). If you use malloc() to get
 space for your shared memory (ie. to fix the `brk'), you must ensure you
 get an unmapped address range. This means you must mallocate more memory
 than you had ever allocated before. Memory returned by malloc(), used,
 then freed by free() and then again returned by malloc is no good.
 Neither is calloced memory.
 
    Note that a shared memory region remains a shared memory region until
 you unmap it. Attaching a segment at the `brk' and calling malloc after
 that will result in an overlap of what malloc thinks is its space with
 what is really a shared memory region. For example in the case of a
 read-only attach, you will not be able to write to the overlapped
 portion.
 
 1.8.3 Fork, exec and exit
 -------------------------
 
 On a fork, the child inherits attached shared memory segments but not
 the semaphore undo information.
 
    In the case of an exec, the attached shared segments are detached.
 The sem undo information however remains intact.
 
    Upon exit, all attached shared memory segments are detached.  The
 adjust values in the undo structures are added to the relevant semvals
 if the operations are permitted. Disallowed operations are ignored.
 
 1.8.4 Other Features
 --------------------
 
 These features of the current implementation are likely to be modified
 in the future.
 
    The SHM_LOCK and SHM_UNLOCK flag are available (super-user) for use
 with the `shmctl' call to prevent swapping of a shared segment. The user
 must fault in any pages that are required to be present after locking
 is enabled.
 
    The IPC_INFO, MSG_STAT, MSG_INFO, SHM_STAT, SHM_INFO, SEM_STAT,
 SEMINFO `ctl' calls are used by the `ipcs' program to provide
 information on allocated resources. These can be modified as needed or
 moved to a proc file system interface.
 
 
 
 
    Thanks to Ove Ewerlid, Bruno Haible, Ulrich Pegelow and Linus
 Torvalds for ideas, tutorials, bug reports and fixes, and merriment.
 And more thanks to Bruno.
Info Catalog
(ipc.info.gz) shmlimits
(ipc.info.gz) Top
automatically generated by info2html