From owner-freebsd-questions Mon Jan 17 19: 4:54 2000 Delivered-To: freebsd-questions@freebsd.org Received: from alpha.pit.adelphia.net (alpha.pit.adelphia.net [24.48.44.2]) by hub.freebsd.org (Postfix) with ESMTP id 98AE114DA9 for ; Mon, 17 Jan 2000 19:04:48 -0800 (PST) (envelope-from evstiounin@adelphia.net) Received: from evstiouninadelphia (surf71-177.pit.adelphia.net [24.48.53.177]) by alpha.pit.adelphia.net (8.9.2/8.9.2) with SMTP id WAA07048 for ; Mon, 17 Jan 2000 22:05:00 -0500 (EST) Message-ID: <004701bf6161$2568a440$b1353018@evstiouninadelphia.net.pit.adelphia.net> From: "Mikhail Evstiounin" To: Subject: Re: Volatile variables Date: Mon, 17 Jan 2000 22:07:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Oliver Fromme To: freebsd-questions@FreeBSD.ORG Date: Monday, January 17, 2000 2:56 PM Subject: Re: Volatile variables >Mikhail Evstiounin 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: > > > [...] 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 > [...] > > > > 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. > > > > 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" [...] > > >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