From owner-freebsd-questions Sun Jan 16 20:57:23 2000 Delivered-To: freebsd-questions@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id C3BA714E80 for ; Sun, 16 Jan 2000 20:57:16 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.9.3/8.9.3) id FAA88762; Mon, 17 Jan 2000 05:57:15 +0100 (CET) (envelope-from olli) Date: Mon, 17 Jan 2000 05:57:15 +0100 (CET) Message-Id: <200001170457.FAA88762@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-questions@FreeBSD.ORG Reply-To: freebsd-questions@FreeBSD.ORG Subject: Re: Volatile variables X-Newsgroups: list.freebsd-questions In-Reply-To: <85rdp2$g65$1@atlantis.rz.tu-clausthal.de> User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.4-19991219-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mikhail Evstiounin wrote in list.freebsd-questions: > From: Oliver Fromme >>No, it's _exactly_ the same, as far as the compiler is >>concerned. The meaning of "volatile" is to prevent the >>compiler's optimizer stage from assuming that the content >>of a variable cannot change _asynchronously_ between >>C statements. The important word is ``asynchronously''. >>It means changes to variables outside of the control flow >>which is known to the compiler at compile-time. This >>includes signal handlers just as well as hardware registers, >>shared memory etc. > > 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". > 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. > 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. > [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 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. 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. > 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? > 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. > 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. ;-) I'd recommend that you read the section about "volatile". 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: 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. 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