Posix 1003.4 vs. volatile.

[Moderator, John S. Quarterman]

From: Ronald Guilmette <uunet!ics.UCI.EDU!rfg>

In article <615 at longway.TIC.COM> daveb at llama.rtech (David Brower) writes:
>From: daveb at 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 at longway.TIC.COM> Ronald Guilmette <rfg at ics.UCI.EDU> writes:
>>From: Ronald Guilmette <rfg at ics.UCI.EDU>
>>In article <5106 at 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 at ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.


Volume-Number: Volume 19, Number 52