Date: Mon, 17 Jan 2000 22:07:24 -0500 From: "Mikhail Evstiounin" <evstiounin@adelphia.net> To: <freebsd-questions@FreeBSD.ORG> Subject: Re: Volatile variables Message-ID: <004701bf6161$2568a440$b1353018@evstiouninadelphia.net.pit.adelphia.net>
next in thread | raw e-mail | index | archive | help
From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de>
To: freebsd-questions@FreeBSD.ORG <freebsd-questions@FreeBSD.ORG>
Date: Monday, January 17, 2000 2:56 PM
Subject: Re: Volatile variables
>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.
I just reread all my postings here and didn't find that I claimed this.
Maximum what I claimed is"
"
Wrong, wrong and wrong. Hardware generates interrupts,
changes statues and value in hardware registers totaly async
and this process is out of your control. Hardware register
can change its value even during totally masked status of CPU.
"
I don't remember that I told that CPU could be interrupted in the middle of
command. But I was talking that hardware can geberate interruption even CPU
is in the middle of the command. That's still true. CPU has usualy one line
for interruption (well, I am talking about intel architecture now, because,
there are CPUs with multiple int lines) and can masked it wit command cli or
open it with command sti. Ther e is an interuptoin controller - completely
another chip - it has 8 lines for different hardware and priorities
(everything could programmed). That's why first IBM PC had 8 ints. Then
somebody cascaded two controllers and it's how all PC have 15 ints now.
Controller(s) maps all this line to the one CPU line. That's why you can
completely stop cpu in a real mode by the following sequence:
cli
hlt
Moreover if you have appropriate rights, you can still do it in protected
(or priveledge) mode. Intel 386 architecture has 4 rings of protections,
most of operating systems use barely 2 - it's much simplier. From the point
of CPU, there is no async interruption. CPU, usually at the begining of
command execution (better to say at some stage of command execution) polls
the state of interruption line and, if there is a signal, then it will do
something - call handler, for example. So you cannot interrupt CPU in the
middle of command, but hardware can generate signal in the middle of
execution - signal will not be hadled immidiatelly, but it's still there.
>
> >>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.
>
I am looking at this a little bit differently - if sighandler is going to
change any value then vilotile is not enough. But for reading purpose - it's
OK.
>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.
>
> >> > 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
I wish I could do it too:-)
>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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I believe, this one of the key words
> 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"
^^^^^^^^^^^^^
this is a slang, but I was talking exactly about this - avoid "too smart"
optimizations, but not all of them.
> 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.
This is my point. But my reading is slightly different: 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.
>
>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
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?004701bf6161$2568a440$b1353018>