kean@pscnet.UUCP (Kean Johnston) (10/04/90)
Please could someone clarify a point for me relating to shared memory under
SCO Xenix, specifically Xenix/386 release 2.3.2 or 2.3.3.
In his excelent book "Advanced Unix Programming" by Marc J. Rochkind,
in the chapter on IPC's and shared memory he states that under Xenix, after
having mapped a segment as shared, you have to unmap it before you can
issue any system calls. This means that you have to keep on mapping and
unmapping the shared data segment each time you need to make a system call.
Is this still true of Xenix, or is the book just outdated. It WAS written
6 years ago after all.
Also, is there any MAJOR speed advantage of using shared memory over
semaphores? Anyone really pushed semaphores to the limit out there ?
Any help at will would be greatly appreciated.
Thanks in advance,
--
Kean Johnston: kean@pscnet.UUCP Bang: ..!ddsw1!olsa99!tabbs!pscnet!kean
-----------------------------------------------------------------------------
"I think; therefore I AM" - Rene Descartesdkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) (10/07/90)
In article <1589@pscnet.UUCP> kean@pscnet.UUCP (Kean Johnston) writes: >Please could someone clarify a point for me relating to shared memory under >SCO Xenix, specifically Xenix/386 release 2.3.2 or 2.3.3. >In his excelent book "Advanced Unix Programming" by Marc J. Rochkind, >in the chapter on IPC's and shared memory he states that under Xenix, after >having mapped a segment as shared, you have to unmap it before you can >issue any system calls. This means that you have to keep on mapping and >unmapping the shared data segment each time you need to make a system call. >Is this still true of Xenix, or is the book just outdated. It WAS written >6 years ago after all. It's outdated. We attach a couple of segments of shared memory at the start of essentially all of our programs and use it as ordinary memory. if you do use it, I should mention one difficulty we've had with it. There is a bug in the implementation of shared memory in 2.2.3 (it may have disppeared in 2.3.2, we've never tested) forced us to allocate a few extra bytes at the end of a shared memory segment or else accessing the last byte caused a program crash. -- Dave Eisen Home: (415) 323-9757 dkeisen@Gang-of-Four.Stanford.EDU Office: (415) 967-5644 1447 N. Shoreline Blvd. Mountain View, CA 94043
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (10/07/90)
In article <1589@pscnet.UUCP> kean@pscnet.UUCP (Kean Johnston) writes: >In his excelent book "Advanced Unix Programming" by Marc J. Rochkind, >in the chapter on IPC's and shared memory he states that under Xenix, after >having mapped a segment as shared, you have to unmap it before you can >issue any system calls. He must be referring to "sdget" XENIX shared memory versus "shmget" System V memory. In a non-8086 system (i.e., 80286 and above), this is not true of either type of shared memory segment. The man sez you must use sdenter() and sdleave() around references to "sdget" -style segments, but this is not true on mapped/paged systems. (I DON'T want to know what it takes to support shared memory on 8086 XENIX.) >Also, is there any MAJOR speed advantage of using shared memory over >semaphores? Anyone really pushed semaphores to the limit out there ? I have a multitasking simulator environment with emulates an embedded system "OS" called pSOS. I have seen 1800+ semaphore operations per second on a 20Mhz 386. The purpose of the semaphores are to lock access to a shared memory segment which simulates VME-bus shared memory. I get 900+ pSOS "context switches" per second, so I feel like that is fast enough to say I have pushed it a bit. ----------------------------------------------------------------------- Warren Tucker, March Hare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "Tell the moon; don't tell the March Hare: He is here to look around."