GNU Info

(ipc.info)Notes

---

Next: Top Prev: shmlimits Up: Top

---

Enter node , (file) or (file)node

Miscellaneous Notes
===================

   The system calls are mapped into one - `sys_ipc'. This should be
transparent to the user.

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.

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.

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.

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.