Re: [9fans] const

[Richard Bilson <rcbilson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

On 12/9/05, David Leimbach <leimy2k@gmail.com> 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 something similar.

And yes, C99 has inline, but to make things interesting they gave it a
slightly different meaning than in C++.

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]