where to place shared memory segments?

Chris Lewis clewis at ferret.ocunix.on.ca
Mon Feb 4 08:24:07 AEST 1991


In article <1991Jan30.174346.28676 at bernina.ethz.ch> lubich at komsys.tik.ethz.ch (Hannes Lubich) writes:
>Hi,
>following figure 2.2 and his remark regarding shmbrk below figure 3.30
>in W. Richard Stevens'book "Unix Network Programming" it seems that
>shared memory segments are "normally" placed between the heap and the
>stack segment of a process address space. I was asked recently why such
>segments couldn't be put on the heap just as other dynamically allocated
>data structures.

>Besides the argument that heap administration is something totally unrelated 
>to allocation of shared memory segments, ist there any serious problems with
>placing shared memory on the heap? Are there any advantages, even?
>Thanks a lot in advance

There's a number of difficulties in implementation, as well
as some oddness later:
	- the kernel has no way of telling what linkage structure
	  your program is using to manage heap space - arbitrarily
	  adding a hunk on top would probably end up confusing malloc
	  and friends, certainly because the kernel couldn't update
	  the various linked lists.  Worse if you tried to free()
	  one expecially followed by a shared memory detach.
	- these areas have to be allocated (usually) as pages,
	  and cannot overlap other areas.
	- worse, these areas may be logically detached from a
	  process.
(Yes, I know malloc/free don't necessarily have to have contiguous
sbrk's, but putting shared memory into the heap would just tend
to confuse things.)

There's no real advantage to doing it in the heap.  One might suggest
the gain of address space, but it would take up the same amount
either way because of the page alignment requirements.
-- 
Chris Lewis, Phone: (613) 832-0541, Internet: clewis at ferret.ocunix.on.ca
UUCP: uunet!mitel!cunews!latour!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request at eci386)
Psroff enquiries: psroff-request at eci386, current patchlevel is *7*.



More information about the Comp.unix.questions mailing list