Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!ukma!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.lang.c Subject: Re: volatile: a summary Summary: right answer, wrong reason Message-ID: <367@proxftl.UUCP> Date: 22 Jun 88 03:08:23 GMT References: <11837@mimsy.UUCP> Organization: Proximity Technology, Ft. Lauderdale Lines: 135 In article <11837@mimsy.UUCP>, chris@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@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.