Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : David Schwartz
Date : Mon Jul 18 2005 08:36 pm


"Mayan Moudgill" <mmoudgill@sandbridgetech.com> wrote in message 
news:11dopdc6l57sfec@corp.supernews.com...

> However, the concept of no-memory-reordering is orthognal to whether or 
> not the variable is shared.

    I do not agree. Future hardware may make it impossible to prevent 
reordering of operations to unshared memory, since there doesn't seem to be 
any point to it.

>> Personally, I would hate to see things added to C that make hidden 
>> assumptions about the hardware.

> This makes *no* assumptions about the hardware; it is a compiler directive 
> restricting the compiler from reordering memory in certain ways that would 
> otherwise be legal.

    That's crazy talk. The C standard doesn't specify what the compiler 
should do, it specifies what the compiler should emit code to make the 
implementation do.

> Consider the case of
>
> acquire(&lock)
> do_something(&x)
> release(&lock)

> It may be perfectly legal in C for a compiler to reorder the operations 
> as:
> do_something(&x)
> acquire(&lock)
> release(&lock)
> even if lock and x are declared volatile.

> The addition of a barrier will prohibit this (otherwise legal) reordering.

> Note: nothing to do with hardware, everything to do with compilers.

    Exactly, and that's why it should not be part of the C language. The C 
language should be about how you get the hardware to do things, not how the 
compiler emits code.

    Seriously, it is a *huge* layering error to think of the language 
specification as telling the compiler what to do. The compiler must do 
whatever it takes to make the *platform* do what the standard requires. The 
standard specifies what happens when you run the code, not what instructions 
the compiler emits.

    DS

.