volatile: a summary

[T. William Wells]

In article <11837 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
>      [volatile] is a keyword in the draft proposed ANSI C standard, and
> it is an attribute of some kinds of variables.  As an attribute, it can
> be applied to objects such as device registers or shared memory
> regions, but not to `ordinary memory'.

Uh, didn't you forget things referenced by signal handlers?

>
>       Is volatile necessary?
>
> This question must be broken down to parts before it can be answered.
> Is the concept necessary?  Is the keyword necessary?  Is the keyword
> useful?  Is the keyword a `good thing'?
>
>       Is the concept necessary?  That is, is the `volatility attribute'
>       a real thing?
>
> Not always.  Many applications have no need for the concept.  Programs
> that compute Fibonacci numbers, or that list files, or do any number
> of useful things may never care about it.  It can be vital to others,
> such as device drivers.
>
>       Is the keyword necessary?
>
> No.  (As an existence proof, consider compilers that do not now have
> the keyword.  Most of them work by not doing much in the way of
> optimisation.  There is more to it, though.)

This is really quite irrelevant.  One could ask the question: is
C really necessary, and answer: No.  For the same "reason".  (As
an existence proof, consider human existence, which was and still
would be doing fine without C.  Most people today do not even
know it exists.) Such is the nature of this kind of "reasoning".

The question, when asking about some human invention, is not: is
it necessary, but rather: does it serve a need?  There also is
the subsidiary question: assuming it does serve a need, does it
create more of a problem than it solves?

> A perfect compiler would know as much as all its programmers combined,
> and could use whatever rules those programmers would use to detect
> `real volatility'.

As I have said in a previous posting, `real volatility', while it
may be apparent in a program, is not an attribute of the program
or of any part of it; rather, it is an attribute of the design of
the program.  Thus, while a compiler MAY be able to discover that
the design implies volatility of an object, there is no way,
short of telling it, that the design requires volatility.  Recall
my example of a UNIX scheduler.

> (Note that computing `real volatility' can be as hard as solving the
> halting problem.  I claim only that the compiler can use the same rules
> that a programmer would use.

Let me repeat...  volatility is NOT an attribute of the program.
As another example, and one I hope will lay this to rest,
consider two programs, both illustrating the use of semaphores.
The only difference between the programs is that one has the
semaphore variable declared volatile and the other does not.
Your professor hands you both and says: run the non-volatile
version and make it break, thus illustrating the necessity of the
volatile keyword when using semaphores.  Then, run the second one
through whatever tests you can come up with to demonstrate that
it won't break.  Both programs are valid: both serve their
purpose.  The only difference between them is the volatility of
the semaphore variable.  No compiler CAN decide whether the
variable should be volatile.

Admittedly, this example is contrived.  (So don't bother to flame
about that.) But it does serve the purpose: to illustrate my
point about designed-in volatility vs.  the kind of volatility
that everybody else seems to be talking about.  They are not the
same.  In the real world, this designed-in volatility is not
always relevant, many programs will have only the "standard"
volatility whose presence or absence could be discoved by the
compiler.  (But note that in my contrived example, said compiler
will give the WRONG result.)

However, certain systems have the characteristic that their
correct function depends on certain objects being volatile, but
nowhere in the program does there have to be evidence of this.
As I said in my previous posting, resource managers (operating
systems, for example) are prone to this problem.  (Here also, the
compiler could be mistaken.)

So, what does the volatile keyword get you?  It informs the
compiler of the fact that a program will not run as intended, for
whatever reason, unless the compiler assumes that something
outside its paradigm can change the object at any time.  It is
telling the compiler that it is a matter of DESIGN of the program
that it will not work without this assumption.  By having a
keyword to inform the compiler of this fact, the compiler may
validly assume that any objects not so tagged are not volatile,
thus permitting a greater degree of optimization.

Thus the answer to the question "does it serve a need?" is
definitely yes.

The basic problem with adding things like the volatile keyword to
the language is that by making the language bigger it makes
things more difficult all around.  Fortunately for this keyword,
there are only two groups of people who even have to know that it
exists: compiler writers and those who need to use volatile
objects.  The first group of people do not seem to be terribly
put out by the volatile keyword (and, since I have a good idea of
what implementing it entails, I am not really surprised).  The
second group of people are the specific people for whom the
volatile keyword was created, they are certainly not going to be
inconvenienced by its existence!

The subsidiary question "does it create more of a problem than it
solves?" also has an easy answer: no.

>     Summary of the summary:
>       Is the concept necessary?       Yes.
>       Is the keyword necessary?       No.
>       Is the keyword useful?          Yes.
>       Is the keyword a `good thing'?  Opinion: yes.

Given these two answers, I think it more than mere opinion that
the volatile keyword is a good thing.

> --
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
> Domain:       chris at mimsy.umd.edu     Path:   uunet!mimsy!chris

We do not disagree about the desirability of volatile.  My basic
reason for harping on this is to make sure that all understand
that there is information that the programmer knows which is not
present in the program itself.  (It is another argument as to
whether it OUGHT to be in the program, and how it ought to be
presented; this is how I view the volatile argument.) This is
true of a lot of information, not just volatility of objects.