Subject: Re: [linux-audio-dev] shared memory problems
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Sun Nov 11 2001 - 18:05:14 EET
On Sun, 11 Nov 2001, Paul Davis wrote:
> >> if you call shmat(2) or mmap(2) with a specific address, the kernel
> >> assumes that you know what you're doing and unmaps anything thats
> >> already mapped there.
> >
> >No it doesnt.
>
> did you even bother to run my test program?
No, sorry. Indeed it does - it is even specified to do so. From SUS on
mmap:
[...]
The mapping established by mmap() replaces any previous mappings for those
whole pages containing any part of the address space of the process
starting at pa and continuing for len bytes.
[...]
SUS doesnt specify what happens for the overlapping region, so its legal
to discard previous mappings (and linux 2.4.x should do so, as its sysv
shm support is based on mmapping anonymous memory). Further for the
starting address SUS says
[...]
If shmaddr is a null pointer, the segment is attached at the first
available address as selected by the system.
[...]
So the linux manpage for shmat is wrong here.
> >Whee - you're not trying to use pointers stored within a shared memory
> >segment, no? Thats obviously broken and _will_ fail badly sooner than
> >you think of it. Use offsets to the shared memory segment instead.
>
> its not obviously broken. its one of the most well known uses of
> shared memory, and its precisely why shmat (id, 0, 0) is documented to
> work in the particular way that it does. this is a technique i've used
> in the past on Interactive Unix, on Mach, on Ultrix and on Solaris.
You happen to be lucky then :) The standards dont say anything that would
make me believe that this should work.
> >See above - you shalt not depend on being able to attach a shared memory
> >segment to the same address in different processes.
>
> yes, you can't *depend* on it. in theory, it might not work. but if 2
> conditions are satisfied, it will:
>
> 1) for the particular set of mappings in question,
> they are all initiated in the "client" processes
> before other calls to mmap(2) and shmat(2) with 0
> as the requested address.
Not from the spec (from the linux shmat manpage yes, but...).
> 2) shmat works in the fashion described by the man page,
> using an unmapped area that other mechanisms will not
> operate on (like ld.so)
This is no longer true for 2.4.x
> these are easy enough to satisfy (with a small wrapper around
> shmat(2)). i've also written to the kernel list to ask why sys_shmat()
> doesn't conform to the SVID specification in its use of the "unmapped
> area".
>
> the one limitation is if you use *2* API's that try this trick in the
> same process. that one is going to be very hard to make work without
> doing old-x86 style "segment:offset" addressing. for now, i don't want
> to go th
Well - as shmat does behave the same as mmap (discarding previous
mappings for a fixed address attach), you have to test, if the region is
already occupied (umm, reading and playing with signals - cant think
of another way at the moment). Also segment:offset addressing is not
that difficult, if you design the data in shm to avoid having pointers
in the first place (i.e. use arrays + indexes rather than linked lists,
etc.) - also a macro for "dereferencing" hides the complexity.
Richard.
-- Richard Guenther <richard.guenther_AT_student.uni-tuebingen.de> PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57 WWW: http://www.anatom.uni-tuebingen.de/~richi/
This archive was generated by hypermail 2b28 : Sun Nov 11 2001 - 18:00:28 EET