>|> I have written a X windows video sequence viewer, which uses the X shared memory
>|> extentions and operates up to speeds of 80 frames per second on a SPARCstation
>|> IPC (it has its own disk). I read in up to 150 frames initially each of size
>|> 64K and store them in shared memory (shmget etc.)
>|> I then write them to the screen as quickly as possible.
>Use the library call plock(), available on SunOS to lock down
>process, text, or data segment in memory. Note that this requires
>root privilege and can obviously have other side effects.
>On another note, I know that system V used to lock down any shared
>memory automatically, in SunOS I see that in 4.1.2 this is currently
DONT use shared memory for this application! Use mmap and map the files
with your frames directly into memory. Then access them from there. To
make sure that the mapped segments are actually in memory, use plock as
above or mlock (if you are root). It has been demonstarted that
applications of this type should always use mmap rather than read and
write, since read and write use twice as much memory. Also, if your frames
wont all fit in memory, you can use madvise to tell the OS how you shall
be accessing the file and it will do things like read ahead for you, so
that by the time you come to accessing the memory mapped pages, the OS has
already brought them into memory while the disk was inactive because you
were writing the last frames to the screen.
Also, shared memory is treated as an anonymous page by the paging daemon,
and shared memory pages will be the first to be thrown out to swap when a
demand for memory arrises, whereas memory mapped pages, since they are
associated with a file descriptor, have the pager trying to keep them in
main memory in anticipation of someone accessing them.
>Shai Guday | Stealth bombers,
>OS Software Engineer |
>Thinking Machines Corp. | the winged ninja of the skies.
>Cambridge, MA |
CSSC Sydney, AOTC, Australia. ph +61 2 3953469 fax +61 2 395 3225