Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!uc!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!emory!kd4nc!n4hgf!wht
From: wht@n4hgf.Mt-Park.GA.US (Warren Tucker)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Shared Memory on SCO Xenix
Keywords: shmem Xenix
Message-ID: <225@n4hgf.Mt-Park.GA.US>
Date: 7 Oct 90 05:10:16 GMT
References: <1589@pscnet.UUCP>
Reply-To: wht@n4hgf.Mt-Park.GA.US (Warren Tucker)
Organization: Amateur Radio Station N4HGF
Lines: 28

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."