std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (04/05/90)
From: Ronald Guilmette <uunet!ics.UCI.EDU!rfg> In article <615@longway.TIC.COM> daveb@llama.rtech (David Brower) writes: >From: daveb@llama.rtech (David Brower) > >First, let me emphasise a point. The Posix proposal is not requesting a >change in ANSI C. It is saying that if a vendor is providing an C >environment that is supposed to work with shared variables, either in >shared memory or through the use of threads, than that environment needs >to meet some additional criteria to conform to 1003.4 So far, that sounds reasonable. > Among these is >that it not be necessary to put "volatile" in front of declaration in >the universe for things to work right. Here's where I diverge with 1003.4. > >In article <601@longway.TIC.COM> Ronald Guilmette <rfg@ics.UCI.EDU> writes: >>From: Ronald Guilmette <rfg@ics.UCI.EDU> >>In article <5106@rtech.rtech.com> I write: >>>Posix 1003.4 is the "real time" extension to Posix. It encompasses >>>shared memory and threads. By including these features it introduces >>>some new restrictions on the compilation environment, the gist of >>>which are that almost everything needs to be treated as "partially >>>volatile" (my phrase). The purpose of this note is to explore the >>>sense of the community tuned to ANSI C to see if this presents a >>>problem. I *don't* have any problems with the proposed Posix >>>restrictions, and in fact consider them essential. I do suspect that >>>some compiler writers may have some objections. Some of the tricks >>>now used by "hyper-optimizing" compilers would be illegal. >>> >>>The Draft 1003.4 Std. says in section 13.2: >. . . > >>Is it just me or does this strike anyone else as being pure gibberish? >>Are these "problems" defined somewhere? Perhaps with examples of how >>these "problems" could crop up in some actual code? > >Yes, they are defined in the proposal; perhaps it is unfortunate that I >did not chose to type is in in it's entirely, including all the EQN >equations. Sorry. Many of Ron's rhetorical questions are answered >there. I'd like to apologize to the entire net for foaming at the mouth in my previous posting on this subject. The problem was that I was under the mistaken impression that the material which was posted *was* in fact the entire relevant section of the draft 1003.4 proposal. I know better now, and I'm sorry. I have since been in communication with one of the members of the 1003.4 committee who has set me straight on a lot of things. Now that I've had a chance to consider the *specifics* of what he is proposing, I have to say that I'm impressed that some members of the committe have in fact been doing their homework. Still, even though the proposal which has been presented to me is quite technically detailed, and takes into account a large number of possible ramifications for various traditional and avant-guard architectures, I have to say that I'm still not fully in agreement with it. I feel that the proposal I have seen has several significant shortcommings. Still, I'm very much happier than I was before because *now* I at least have something quite detailed and concrete to pick at and to directly compare "volatile" with. >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. Not by a long shot! Is is saddening to hear such false generalizations made in public, and I have hopes that this is only the opinion of the poster, and not of 1003.4 as a whole. >>> The keyword causes inefficient code to be generated because any >>> reference or store into a volatile variable must be immediately >>> reflected in all other streams of execution, defeating any >>> optimization or caching. Some folks may have been under the impression that *all* things protected by a mutex would have to be volatile in order for volatile to be useful (and used) for multi-threaded programming. This is *not* necessarily the case, and it may be possible to make only the mutex itself volatile. You kinda have to do that anyway. Thus, this "inefficiency" of volatile, which some folks may be worried about may not be as bad as some fear. In fact, it may actually approach zero on many architectures, and it may actually *be* zero on many others. // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway. Volume-Number: Volume 19, Number 52
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (04/13/90)
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