On Wed, 15 Aug 2007, Paul E. McKenney wrote:

On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:

quoted

Herbert Xu wrote:

quoted

On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:

quoted

quoted

I don't know if this here is affected:

[...something like]
	b = atomic_read(a);
	for (i = 0; i < 4; i++) {
		msleep_interruptible(63);
		c = atomic_read(a);
		if (c != b) {
			b = c;
			i = 0;
		}
	}

quoted

Nope, we're calling schedule which is a rather heavy-weight
barrier.

How does the compiler know that msleep() has got barrier()s?

Because msleep_interruptible() is in a separate compilation unit,
the compiler has to assume that it might modify any arbitrary global.
In many cases, the compiler also has to assume that msleep_interruptible()
might call back into a function in the current compilation unit, thus
possibly modifying global static variables.

Yup, I've just verified this with a testcase. So a call to any function
outside of the current compilation unit acts as a compiler barrier. Cool.