Date: Mon, 17 Jan 2000 20:55:48 +0100 (CET) From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de> To: freebsd-questions@FreeBSD.ORG Subject: Re: Volatile variables Message-ID: <200001171955.UAA88876@dorifer.heim3.tu-clausthal.de> In-Reply-To: <85v96r$2jjd$1@atlantis.rz.tu-clausthal.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Evstiounin <evstiounin@adelphia.net> wrote in list.freebsd-questions:
>>No. Except if your processor is broken. :-)
>
> Oliver, what about timer registers or serial interface registers?
> what about mapped video memory or shared memory in multi
> CPU system?
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.
>>There is no concurrency. Even if you have two processors,
>>the signal handler will not run in parallel to the "main"
>>part of the program.
>
> I agree completely, I was trying to stress a difference between sighandler
> and threads and unix processes.
Oh, then I misunderstood you, sorry. Of course, a sighandler
is something completely cifferent. :-)
>>But setting singal masks does not prevent those register
>>optimizations. You _must_ use "volatile" for this.
>
> In a way, how you proposed - yes, but it's not enough.
It depends on the program, and what it uses the variables for.
That's a different issue, not subject to this discussion.
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. :-)
>> > Vilotile tells to compiler (and to programmer)
>> > that j can have a very strange result.
>>
>>That's completely wrong.
>
> So, if programmer wites j = i * i; (s)he doesn't expect to get a square? I
> understand, that according to standard vilotile means it, but it's not
> intuitive. That's why I told that vilotile tells to compiler and to
> programmer - expect something strange.
No, that's still wrong.
Without volatile, you can get exactly the same "strange"
result.
You asked me to quote from the standard. This is not easy,
because volatile is mentioned in a lot of places, and I don't
have it in *.txt form, so I have to type everything manually
from it. Here are a few sections which I think are pretty
important:
<quote>
[...] an implementation might perform various optimizations
within each translation unit, such that the actual semantics
would agree with the abstract semantics only when making
function calls across translation unit boundaries. [...]
In this type of implementation, objects referred to by
interrupt service routines activated by the signal function
would require explicit specification of "volatile" storage
[...]
</quote>
<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"
by an implementation or reordered except as permitted by the
rules for evaluating expressions.
</quote>
<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>
It sounds like you cannot even read a global variable inside a
signal handler, even if it's volatile. I didn't know this
before (and I think it's strange), but that's what the standard
says.
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?200001171955.UAA88876>