Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.questions Subject: Re: SVR4 vs BSD (was AIX (is it unix)?) Message-ID: <19843@mimsy.UUCP> Date: 27 Sep 89 21:08:12 GMT References: <1702@naucse.UUCP><2508@auspex.auspex.com> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 36 >>... semaphored memory In article <2508@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >"Semaphored memory"? Oops, typo: I meant `semaphore memory'. The mmap() call in 4.4BSD will (assuming it gets implemented!) require a special flag (which might well be a pseudo-flag, i.e., 0) in order to map for use as semaphores. As Kirk put it, I believe that shared memory is an interesting IPC mechanism only if semaphores can be mostly done without system calls, and hence must be provided for in the interface. HASSEMAPHORE provides this hook; some multiprocessors require that semaphores be in uncached memory or only in semaphore registers. This flag would allow the system to set up such uncached regions when it knew that semaphores were going to be used. For machines with hardware semaphore registers, the flag would cause the mmap with HASSEMAPHORE set to fail on anything other than a mapping of the special device associated with those registers. Presumably the interface to semaphores used for shared memory will be hidden in a library routine. >OK, you were referring to the *interface* design ... Quite. >[which] is derived from the stuff described in the 4.2BSD paper, but not >implemented in 4.xBSD (except perhaps trivially for some device drivers, >just as was the case in SunOS prior to 4.0.) (Not even in any drivers.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris