From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <676c3c4f0512091117j5acef713g7438f12d7d9f9c24@mail.gmail.com> Date: Fri, 9 Dec 2005 14:17:46 -0500 From: Richard Bilson To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] const In-Reply-To: <3e1162e60512090942w50850e9cv9a8d8d4870a6e81c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9406_22632198.1134155866510" References: <3e1162e60512090825n4d944cc8yb2f668e3deb64dec@mail.gmail.com> <676c3c4f0512090859n72ec5bd1rfa7742b43faf526b@mail.gmail.com> <3e1162e60512090942w50850e9cv9a8d8d4870a6e81c@mail.gmail.com> Topicbox-Message-UUID: c0548e38-ead0-11e9-9d60-3106f5b1d025 ------=_Part_9406_22632198.1134155866510 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/9/05, David Leimbach wrote: > > > 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 optiona= lly > 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?] The difference is that with memory barriers it's often the case that the correctness of the algorithm depends on the placement of the barriers. Consider writing a portable spin-lock: it's crucial that other processors not be able to observe the lock open unless they also observe previous memory writes in the critical section. But, in the absence of memory barriers, many CPUs don't guarantee this. The simple answer, of course, is to put the barriers in non-portable lock code and use the locks to protect shared state. But the general experience seems to be that programmers will try anything to avoid locks, for performance reasons. Double-checked locking is the classic example -- it's such a popular idiom that Java redefined the meaning of "volatile" to make it work. C++ will probably do something similar. And yes, C99 has inline, but to make things interesting they gave it a slightly different meaning than in C++. ------=_Part_9406_22632198.1134155866510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On 12/9/05, = David Leimbach <leimy2k@gmail.c= om> wrote:

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 inline stuff I didn't ask it to.  [C99  has inline now too doesn't it?]

The difference is that with memory barriers it's often the case that the correctness of the algorithm depends on the placement of the barriers. Consider writing a portable spin-lock: it's crucial that other processors not be able to observe the lock open unless they also observe previous memory writes in the critical section. But, in the absence of memory barriers, many CPUs don't guarantee this.

The simple answer, of course, is to put the barriers in non-portable lock code and use the locks to protect shared state. But the general experience seems to be that programmers will try anything to avoid locks, for performance reasons. Double-checked locking is the classic example -- it's such a popular idiom that Java redefined the meaning of "volatile" to make it work. C++ will probably do somet= hing similar.

And yes, C99 has inline, but to make things interesting they gave it a slig= htly different meaning than in C++.
------=_Part_9406_22632198.1134155866510--