Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsp!gillies
From: gillies@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Re: volatile: is NOT a frill, i
Message-ID: <77200031@uiucdcsp>
Date: 9 Apr 88 17:22:00 GMT
References: <3950002@hplvly.HP.COM>
Lines: 20
Nf-ID: #R:hplvly.HP.COM:3950002:uiucdcsp:77200031:000:933
Nf-From: uiucdcsp.cs.uiuc.edu!gillies    Apr  9 11:22:00 1988


That's a very good point:  Since volatile is so machine/application
specific (do I need it on a stack machine?  unlikely!)  It may be a
bad idea to nail it down in a particular way.  For instance:

1.  Do we want volatile to apply to individual variables?
2.  Or would the programmer rather have a directive that makes a clump of
    variables volatile?  After all, it's a pain to make an entire
    module "volatile"
3.  Perhaps we want to have stretches of code that are "volatile",
    (The HP method?) and in other places allow the variables to live in 
    registers or whatever.
4.  I'm sure you can imagine useful applications for the other situations.

Can you honestly predict what these shared-memory multiprocessing guys
really need?  Will they have to reimplement the feature themselves?
If so, then the answer is :  Do not put it in.

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {gillies@p.cs.uiuc.edu}