Date: Mon, 17 Jan 2000 00:53:05 -0500 From: "Mikhail Evstiounin" <evstiounin@adelphia.net> To: <freebsd-questions@FreeBSD.ORG> Subject: Re: Volatile variables Message-ID: <00dc01bf60af$20775ce0$ed353018@evstiouninadelphia.net.pit.adelphia.net>
next in thread | raw e-mail | index | archive | help
-----Original Message-----
From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de>
To: freebsd-questions@FreeBSD.ORG <freebsd-questions@FreeBSD.ORG>
Date: Sunday, January 16, 2000 11:58 PM
Subject: Re: Volatile variables
>Mikhail Evstiounin <evstiounin@adelphia.net> wrote in
list.freebsd-questions:
> > Wrong, wrong and wrong. Hardware generates interrupts,
> > changes statues and value in hardware registers totaly async
> > and this process is out of your control.
>
>Delivery of a signal is, in essence, cause by a hardware
>interrupt, directly or indirectly. It is what you call
>"totally async".
This is one part, but you missed another - value of a register
could be changed completely in the middle of an assembler command.
>
> > Moreover, your process will be stopped as soon as
> > sighandler gets its control.
>
>No, the sighandler is part of the process. When a signal
>handler gets called, this is (simply speaking) like an
>asynchronous and non-foreseeable subroutine call.
If you are talking about process as something in UNIX, I agree
here, but I was talking about process as some essence in sense
of unit of concurrency.
>
> > This process is totally under your control
>
>No, it is not. In particular, the compiler is unable to take
>it into consideration during register optimization.
>
Again, you missed my point - you as a programmer, not as
a compiler. You can mask signals.
> > [useless example with race-conditions deleted]
> > And vilotale doesn't help a bit!!!
>
>True, volatile does not help against typical race-conditions.
>That's not the purpose of volatile. Volatile does not help
I was trying to underline it in all my letters. It shows, that
I am bad speaker:-)
>for basic synchronization, this is the programmer's task, but
>not the task of volatile.
>
>Without volatile, the programmer would be _completely_ unable
>to use global variables within signal handlers, because the
>compiler could hold their values in registers for an indefinite
>amount of time.
>
>In theory, if the processor hardware has enough registers,
>_all_ variables of the whole program could be held in registers
>during the _whole_ lifetime of the process. There would be
>never a variable stored in memory. This is perfectly legal,
>and a programmer whould have no chance to access them from
>within a signal handler.
>
You are wrong here again. I was a member of team that wrote compiler
allocating global variables in registers. And it worked. You,
except some special address scheme and speed there is no big difference
between memory and registers from the point of view of a compiler.
>Volatile is the only solution to that problem. Therefore, it
>is necessary, and a compiler _must_ obey it. It basically
>forbids register optimizations for that particular variable.
>
Hey, I stressed that in every my post - no synonyms.
> > Again, I let myself to cite BS book (p. 808) - "an object can change its
> > value
>
>"BS book"? How about quoting from an authoritative reference?
>
OK, Bjarne Stroustrap is not authorative, even it's a base for standard
or created based on standard drafts?
> > in ways not specified by the language". In my mind, this is very careful
> > and strict statement.
>
>I'm sorry, but I think it's rather misleading.
>
Disagree, but it's my opinion.
> > Any ofthis book or article will show you how to live without
> > vilotile in async process environment.
>
>You cannot solve the problem without "volatile" which I've
>demonstrated above.
>
>The ANSI/ISO C standard is missing in your list of books. ;-)
Yeap, I left almost all my books back in Russia, but I'll try to get it
(standard) as soon as I can. I listed only those I have now.
>I'd recommend that you read the section about "volatile".
>
could you cite for me?
>Yet another example (simplified):
>
> extern int i;
> extern int j;
> void foo (void) { j = i * i; j += i; }
>
>Compiled with ``cc -O3 -Wall -ansi -pedantic -c'', the result is:
>
> movl i,%eax
> imull %eax,%eax
> addl j,%eax
> movl %eax,0x0
>
>Note that there could be other, unrelated statements between
>those two, and the compiler would still be allowed to hold
>everything in registers, if possible. If a signal handler
>is called at this point, you have three problems:
>
>1) If it reads the variable j, it gets the wrong value,
> because j has not been updated yet.
>2) If it writes to i, the value would not be used by the
> function after return from the signal handler.
>3) If it writes to j, the value will be ignored and
> overwritten after return from the signal handler.
>
>In short: The whole thing breaks without volatile.
>
>Adding "volatile" to the declaration of i and j changes the
>code considerably:
>
See my other emails - almost the same.
> movl i,%eax
> movl i,%edx
> imull %edx,%eax
> movl %eax,j
> movl j,%eax
> movl i,%edx
> addl %edx,%eax
> movl %eax,j
>
>As you can see, now the contents of i and j are always
>consistent. This code works fine, even when an asynchronous
>mechanism (signal handler, hardware, etc.) tries to access
>them at some point.
>
For Chrises sake tell me what is going to happen if you got
interrupted after first movl? Didn't you see that? It's exactly
what vilotile means - between two sequential reading you
can get different results. You will have one value on register
eax and completely differend on edx. Vilotile does help
you to avoid synonyms, but doesn't help you to solve your problem.
Don't tell me about C statement as a minimal execution part.
OS has ZERO knowledge about this fact and can deliver
interruption just after the first movl. In other words,
there is no warranty that j will always have value of
square of i. Vilotile tells to compiler (and to programmer)
that j can have a very strange result. And if compiler
will use synonyms for i, this result could be even more
strange (if I can say here more strange).
Oliver, I don't want to tell anybody - don't use vilotile.
Vilotile is very helpfull, but it's not enough to use it when
you have multiple handlers or even one handler.
You must mask signals in some regions of your program.
>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?00dc01bf60af$20775ce0$ed353018>