[cpp-threads] Web site updated

[Paul E. McKenney]

On Tue, Feb 13, 2007 at 05:47:14AM +0200, Peter Dimov wrote:
> Paul E. McKenney wrote:
> 
> >From the load_raw() side, my hope would be that the compiler would be
> >required to "forget" where the value came from, thus being unable to
> >recognize that the following:
> >
> >x = a.load_raw();
> >y = a.load_raw();
> >
> >might be cached -- in other words, there must be a separate load from
> >"a" for both x and y.  Or am I missing your point?
> 
> The compiler is allowed to optimize out the second load since there is no 
> way of enforcing a particular execution, one where something 
> other-thread-ly happens between the two statements. The execution where the 
> current thread is not interrupted between the two loads is legitimate, so 
> the programmer has no grounds to complain if he gets a program that does 
> exactly that.

How is the compiler to optimize out the second load if it has properly
forgotten where it loaded the value in x from?  The load_raw() function
is -not- sequential-program "business as usual" for the compiler, after
all.

> A compiler is not, however, allowed to move the load_raw outside a loop if 
> this can turn a finite loop into an infinite one (this would violate the 
> "eventually"). But it's probably allowed to move it outside a loop that is 
> executed a "small" number of times. And probably not allowed to move it 
> outside a loop executed 10^8 times (if we say that in addition to 
> "eventually", a store needs to become visible to a load_raw in a 
> "reasonably short period"). 

Agreed -- assuming the compiler can evaluate the cost of the loop.  If a
given loop involves a call to an unknown externally defined function,
then I would argue that the compiler is not permitted to defer the
load_raw() or store_raw() across that loop.

							Thanx, Paul