From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60512090942w50850e9cv9a8d8d4870a6e81c@mail.gmail.com> Date: Fri, 9 Dec 2005 09:42:48 -0800 From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] const In-Reply-To: <676c3c4f0512090859n72ec5bd1rfa7742b43faf526b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6416_22214386.1134150168001" References: <3e1162e60512090825n4d944cc8yb2f668e3deb64dec@mail.gmail.com> <676c3c4f0512090859n72ec5bd1rfa7742b43faf526b@mail.gmail.com> Topicbox-Message-UUID: c04127da-ead0-11e9-9d60-3106f5b1d025 ------=_Part_6416_22214386.1134150168001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > It is a matter of faith, and usually misplaced at that, since volatile > isn't usually defined to place any constraints on the order in which > operations become visible to other processors. Certainly not in the C, C+= +, > or POSIX standards, although some platform ABIs do specify this to some > degree. > > Both POSIX and C++ are trying to deal with this, but it's an uphill battl= e > since processors differ widely on the sorts of constraints that they can > support efficiently. > > In the meantime, people sprinkle volatile around and pray. All the world'= s > an x86, right? > I think I'd be happier with new compiler pragmas in this case than a keyword. Then at least I KNOW that it can be ignored and will be optionall= y supported by compilers on a per-case basis. But then again, that's also true for "inline" in C++. It's just a suggestion, one that can be ignored. The compiler can also inline stuff I didn't ask it to. [C99 has inline now too doesn't it?] ------=_Part_6416_22214386.1134150168001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
It is a matter of faith, and usually misplaced at that, since volatile isn't usually defined to place any constraints on the order in which operations become visible to other processors. Certainly not in the C, C++, or POSIX standards, although some platform ABIs do specify this to some degree.

Both POSIX and C++ are trying to deal with this, but it's an uphill battle since processors differ widely on the sorts of constraints that they can support efficiently.

In the meantime, people sprinkle volatile around and pray. All the world's = an x86, right?

I think I'd be happier with new compiler pragmas in = this case than a keyword.  Then at least I KNOW that it can be ignored= and will be optionally supported by compilers on a per-case basis.

But then again, that's also true for "inline" in C++.  It's = just a suggestion, one that can be ignored.  The compiler can also inl= ine stuff I didn't ask it to.  [C99  has inline now too doesn't i= t?]




------=_Part_6416_22214386.1134150168001--