Xref: utzoo comp.lang.c:9795 comp.arch:4547
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!limes
From: limes@sun.uucp (Greg Limes)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: volatile (in comp.lang.c)
Message-ID: <51437@sun.uucp>
Date: 30 Apr 88 05:00:58 GMT
References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <9916@tekecs.TEK.COM> <2642@geac.UUCP> <2082@winchester.mips.COM> <2674@geac.UUCP>
Reply-To: limes@sun.UUCP (Greg Limes)
Organization: Sun Microsystems, Mountain View
Lines: 26

In article <2674@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes:
>
>  I reiterate: the question of the necessity of certain information
>for optimization purposes is:
>	1) in part architectural,
>	2) in part a question of compiler technology, and
>	3) open.
>
>  Specifically:
>	1) what architectures currently use asynchronously-changing
>memory locations for program notification of events? DEC Vax,
>various CDC boxes, MIPS(tm),...

... and any program with a signal handler that modifies a global
variable, which is pretty inclusive if you ask me, it all comes to the
same effect from the POV of both the mainline thread and the
compiler ...

>	2) what other programmer-visible alternatives are there?
>Interrupts, event queues, (Hoare) monitors... 

... use only specific transfer variables, test these only around calls
to synchronous functions that the compiler can never know about and must
assume that they modify these locations ...
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb