From owner-freebsd-questions Tue Jan 18 1:47:13 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 B60FB14FE5 for ; Tue, 18 Jan 2000 01:47:08 -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 KAA42244; Tue, 18 Jan 2000 10:47:07 +0100 (CET) (envelope-from olli) Date: Tue, 18 Jan 2000 10:47:07 +0100 (CET) Message-Id: <200001180947.KAA42244@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-questions@FreeBSD.ORG Reply-To: oliver.fromme@heim3.tu-clausthal.de Subject: Re: Volatile variables X-Newsgroups: list.freebsd-questions In-Reply-To: <860lbt$h56$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 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 wrote in list.freebsd-questions: > From: Oliver Fromme >>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: This is one part, but you missed another - value of a register could be changed completely in the middle of an assembler command. >>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. >> >> 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. >> >> 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" [...] >> 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