Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!apple!agate!darkstar!crhc.uiuc.edu
From: aglew@crhc.uiuc.edu (Andy Glew)
Newsgroups: comp.os.research
Subject: Re: Toy Experiment with Shared Memory Programming
Message-ID: <8947@darkstar.ucsc.edu>
Date: 14 Nov 90 11:57:40 GMT
Sender: usenet@darkstar.ucsc.edu
Organization: Center for Reliable and High-Performance Computing University of
Lines: 27
Approved: comp-os-research@jupiter.ucsc.edu

..> Pipes versus shared memory, spinning on a non-running processor,
..> and scheduling.  [jms@central.cis.upenn.edu (Jonathan M. Smith)]

>I observed a similar problem in Mirage.  Why not read over the article
>"Mirage: A Coherent Distributed Shared Memory Design" in SOSP12 noting the 
>yield() instruction which was added to better control UNIX synchronization
>and scheduling interactions.
>[Brett D. Fleisch]

The yield() operation sounds very much like the suspend()/resume()
facility found in many real-time executives, which I put into Gould
UTX-32/RT. As I recall it took me 45 minutes to prototype - it was
essentially a variant of SIGSTOP, with much reduced overhead - and
maybe a man-month for someone else to productify, after the fact 
design, etc.

Suspend()/resume(), and the combined suspres(), were low overhead
system calls to suspend the current process, and start another process
running. So, in the shared memory pipe example, the producer would
suspend itself and start the consumer when the buffer is full, and the
consumer would vice versa when the buffer is empty.

By the way, some UNIX pipe implementations provide another feature:
they provide a priority boost PPIPE to a process made runnable by a
pipe.
--
Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]