Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : Mayan Moudgill
Date : Mon Jul 18 2005 11:30 pm

David Schwartz wrote:
> "Mayan Moudgill" <mmoudgill@sandbridgetech.com> wrote in message 
> news:11domum9gnvatbe@corp.supernews.com...
> 
> 
>>For instance, we could add a statement __barrier() {don't reorder memory 
>>operations past this statement}
> 
> 
>     Such a statement would be useless unless you also have a way to specify 
> that a variable be put in memory that's visible on other processors. Not all 
> MP machines are SMP machines.

Certainly that may be another extension that is valuable (perhaps 
__shared?)

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

> 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.

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.

.