Xref: utzoo comp.std.c:2778 comp.std.unix:613
Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!longway!std-unix
From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.c,comp.std.unix
Subject: Re: Posix 1003.4 vs. volatile.
Message-ID: <629@longway.TIC.COM>
Date: 12 Apr 90 18:31:28 GMT
References: <5106@rtech.rtech.com> <601@longway.TIC.COM> <615@longway.TIC.COM> <622@longway.TIC.COM>
Reply-To: Doug Gwyn <uunet!brl.mil!gwyn>
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <622@longway.TIC.COM> Ronald Guilmette <uunet!ics.UCI.EDU!rfg> writes:
>>The Posix committee apparently does not feel that it is reasonable to
>>require the programmer to write "volatile" on nearly everything to
>>insure correctness.
>I don't yet know what the committe as a whole feels, but I can assure
>everyone that attaching "volatile" to *everything* is not necessary.

Indeed, only shared variables need to be protected, and only within
critical regions.  This can be enforced locally, without forcing the
variables to be declared as volatile-qualified, through use of
volatile-qualified type casts or block-scope temporary variables.
This technique puts a considerable burden on the programmer, but hey,
he's the one who needs to specify precisely what may be and must not
be cached anyway..

Volume-Number: Volume 19, Number 59