Xref: utzoo comp.unix.wizards:19898 gnu.gcc:1224
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!sol!lll-winken!maddog!brooks
From: brooks@maddog.llnl.gov (Eugene Brooks)
Newsgroups: comp.unix.wizards,gnu.gcc
Subject: Re: Is your system polluted?
Message-ID: <42449@lll-winken.LLNL.GOV>
Date: 26 Dec 89 07:59:15 GMT
References: <1552@aber-cs.UUCP> <259323F0.15070@paris.ics.uci.edu> <PCG.89Dec25215018@rupert.cs.aber.ac.uk>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: brooks@maddog.llnl.gov (Eugene Brooks)
Followup-To: comp.unix.wizards
Distribution: gnu
Organization: Lawrence Livermore National Laboratory
Lines: 15

In article <PCG.89Dec25215018@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes:
>I agree 100%. I agree so much that then I can propose the
>equivalently safe, but almost 100% backward trick that makes the
>ridiculous volatile keyword useless without virtually loss in
>optimization ability and with abosulte safety:
The volatile keyword is not ridiculous, and it is very useful.
Its orginal domain, to support device register access where memory
values would change in a spontaneous way, has expanded to shared memory
multiprocessing.  I am sure that the ANSI committee did not have multiprocessing
in mind when they hatched volatile, but they did us a big favor with it.
It is best to not statically delcare a variable as volatile, however,
it is best to declare a specific reference volatile with a cast when
you need to be sure that the compile does not screw you.

brooks@maddog.llnl.gov, brooks@maddog.uucp