Date: Tue, 18 Jan 2000 10:47:07 +0100 (CET) From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de> To: freebsd-questions@FreeBSD.ORG Subject: Re: Volatile variables Message-ID: <200001180947.KAA42244@dorifer.heim3.tu-clausthal.de> In-Reply-To: <860lbt$h56$1@atlantis.rz.tu-clausthal.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Can't we just let this thread die, please?
The sections which I quoted from the standard are _perfectly_
clean, and I don't think they can be misinterpreted in the way
you do. Please get the document yourself, and read those
sections in whole. And don't forget the definitions of
"shall", "undefined" etc. :-)
Mikhail Evstiounin <evstiounin@adelphia.net> wrote in list.freebsd-questions:
> From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de>
>>It has nothing to do with the issue.
>>You claimed that the processor could be interrupted in the
>>middle of an assembler instruction, which is incorrect.
>>At least for all processor types that I know about.
>
> I just reread all my postings here and didn't find that I claimed this.
Mikhail, you wrote in your posting that arrived here at 17 Jan
2000 05:53:13 GMT:
<quote>
This is one part, but you missed another - value of a register
could be changed completely in the middle of an assembler command.
</quote>
>>It depends on the program, and what it uses the variables for.
>>That's a different issue, not subject to this discussion.
>
> I am looking at this a little bit differently - if sighandler is going to
> change any value then vilotile is not enough.
That statement is wrong. If your sighandler only changes a
variable which is declared ``volatile sig_atomic_t'', and the
rest of the program only reads from it, then it works perfectly
well.
(If other parts of the program want to write to that variable,
too, you have to mask the signal, of course. But this is not
the topic of this discussion, which is only about the necessity
of "volatile".)
>>This discussion is about using the "volatile" qualifier, which
>>is necessary for global variables that are accessed from within
>>signal handlers. You did not agree with this (do you still not
>>agree?), and I'm trying to convince you that it _is_ indeed
>>necessary. :-)
>
> See my comments below - I am not completely disaggree or agree - I
> distinguish different cases for vilotile usage - somewhere I agree,
> somewhere I don't.
Then you're somewhere wrong, I'm afraid. :-)
>> In this type of implementation, objects referred to by
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I believe, this one of the key words
Please read the whole chapter. ``This type of implementation''
is referring to an optimizing compiler (naturally, a compiler
which does not do any optimizations does not have to handle
"volatile" variables in a special way). But since almost all
software is compiled with optimizations, the point is pretty
much irrelevant. Many compilers even perform some simple
("inexpensive") optimizations when you don't specify -O. gcc
is an example of this.
>><quote>
>> A "volatile" declaration may be used to describe an object
>> corresponding to a memory-mapped input/output port or an
>> object accessed by an asynchronously interrupting function.
>> Actions on objects so declared shall not be "optimized out"
>
> ^^^^^^^^^^^^^
> this is a slang, but I was talking exactly about this - avoid "too smart"
> optimizations, but not all of them.
``Avoid "too smark" optimizations'' is pretty sloppy. It is
more accurate to say ``must not use register optimizations''.
And even that is still sloppy -- the description in the
standard is probably most exact.
>><quote>
>> If the signal occurs [...], the behavior is undefined if the
>> signal handler refers to any object with static storage
>> duration other than by assigning a value to an object
>> declared as "volatile sig_atomic_t" [...]
>></quote>
That was probably the most important section, and it's very
clear. There's no need to discuss this any further. :)
> This is my point. But my reading is slightly different:
Then your reading is wrong, I'm afraid.
> if sighandler uses
> variable for "reading" purposes and this variable is not declared with
> vilotile then behavior is undefined, because synonyms could exist and value
> of synonym could be chaged and not synchronized with main copy. In other
> words, vilotile would guarantee that if sighandler reads data, then
> everything is consistant, but if sighandler is trying to write to a
> variable, then vilotile is not enough.
That's not what the above paragraph says. I'm sorry, but I
have no idea how you can misinterpret it in that way
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de)
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001180947.KAA42244>