From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,148d39ae0d22411d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-29 11:22:27 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news2.rdc2.tx.home.com.POSTED!not-for-mail Sender: minyard@wf-rch.cirr.com Newsgroups: comp.lang.ada Subject: Re: Pragma Volatile References: <3BB08F9C.BFB01047@raytheon.com> <3BB10D52.4D455DBA@raytheon.com> <3BB60733.4A80708A@avercom.net> Reply-To: minyard@acm.org From: minyard@acm.org Message-ID: X-Newsreader: Gnus v5.7/Emacs 20.7 Date: Sat, 29 Sep 2001 18:22:27 GMT NNTP-Posting-Host: 24.7.109.109 X-Complaints-To: abuse@home.net X-Trace: news2.rdc2.tx.home.com 1001787747 24.7.109.109 (Sat, 29 Sep 2001 11:22:27 PDT) NNTP-Posting-Date: Sat, 29 Sep 2001 11:22:27 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:13517 Date: 2001-09-29T18:22:27+00:00 List-Id: Tucker Taft writes: > There shouldn't be any problem if you are using this in a mono-processor. (talking about volatiles not being important on uniprocessors). Note that this isn't true at all. Multiprocessors require special instructions for syncronization, but volatile is just as important on a uniprocessor as a multiprocessor. You use it when talking to device registers (which are changed asyncronously or have side effects) or in variables shared between tasks (because you can't necessarily guarantee when tasks switch). You are telling the compiler that the variable has side-effects that it doesn't know about. I assume Mr. Taft know this but was trying to make another point. Note that the rest of what was said was true; I am just addressing this one point. Another way to think about volatiles is that they guarantee that any operation done on the variable is actually done. For instance: A : Integer; . . . A := 1; while (A /= 0) loop delay 1.0; end loop; A compiler would look at this and say "Hey, A doesn't change in the loop, and A is set right before, so this just really just an infinite loop", even if some other task changes A. Setting A volatile guarantees that every time you reference A and compare, it actually get's referenced and compared. Also, consider a register to reset a device, where you write a 0 then a 1 to reset it. B : Register_Access; B.all := 0; B.all := 1; Again, a compiler can say, "Hey, we can just ignore the first operation, because it doesn't have any effect", from the compiler's point of view. But setting B volatile guarantees that both operations get done. Actually, I'm not sure of the syntax here, because what B references is volatile, not B itself. So I'm guessing you would have type Register_Access is access all Integer; pragma Volatile(Register_Access); Instead of making B volatile. This is just like the "C" language, where the location of the "volatile" keyword is very critical to what gets set volatile. -Corey