Xref: utzoo comp.lang.c:9805 comp.arch:4553
Path: utzoo!mnetor!uunet!lll-winken!lll-crg.llnl.gov!brooks
From: brooks@lll-crg.llnl.gov (Eugene D. Brooks III)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: volatile (in comp.lang.c)
Message-ID: <6612@lll-winken.llnl.gov>
Date: 30 Apr 88 16:07:45 GMT
References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <9916@tekecs.TEK.COM> <2642@geac.UUCP> <2082@winchester.mips.COM> <2674@geac.UUCP>
Sender: usenet@lll-winken.llnl.gov
Reply-To: brooks@lll-crg.llnl.gov.UUCP (Eugene D. Brooks III)
Organization: Lawrence Livermore National Laboratory
Lines: 14

>In article <2642@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes:
>|     It is interesting to note that there have not been, to date,
>| **any** other discussion of the necessity of "volatile" et all, only
>| of their desirability in a given language, taking their necessity as
>| **a given**.
Unfortunately, the ANSI C standard proposal did not give much attention to
multiprocessing issues, but the use of volatile in tightly coupled shared
memory programs is very important.  A shared memory variable is often
"cacheable" for a short period of time, and by this I include "cache in the
usual sense" and the use of registers as cache.  Volitile allows the user
to tell the compiler which references are not to be taken from cache, but
obviously needs further development in the context of multiprocessing.
Perhaps this will happen in the second "standards cycle" for C.  With all
the VLSI based multiprocessors hitting the market, good language support
for them will become very important.