On Thu, Feb 26, 2015 at 07:43:01AM -0500, Steven Rostedt wrote:

On Thu, 26 Feb 2015 08:45:59 +0100
Peter Zijlstra [off-list ref] wrote:

quoted

On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:

quoted

It can't be used for state?

If one CPU writes "zero", and the other CPU wants to decide if the
system is in the state to do something, isn't a rmb() fine to use?


CPU 1:

	x = 0;
	/* Tell other CPUs they can now do something */
	smp_wmb();

CPU 2:
	/* Make sure we see current state of x */
	smp_rmb();
	if (x == 0)
		do_something();

The above situation is not acceptable?

Acceptable is just not the word. It plain doesn't work that way.

Thinking about this more, is it because a wmb just forces the CPU to
write everything before this before it writes anything after it. That
is, the writes themselves can happen at a much later time. Does a plain
mb() work the same way if there are no reads required?

No, neither smp_wmb nor smp_mb are required to flush the store buffers.

The only thing barriers do is guarantee order, this can be done by
flushing store buffers but it can also be done by making sure store
buffers flush writes in the 'right' order.

Nor does an rmb help anything with ordering against a possible store
buffer flush. Again rmb only guarantees two loads are issued in that
particular order, it doesn't disallow the CPU speculating the load at
all.

So that load of X could come out of thin air, or a year ago, or
whatever, definitely before any store buffers were, or were not, flushed
on another cpu.

quoted

quoted

Otherwise, we fail to be able to do_something() when it is perfectly
fine to do so.

Can't be helped.

What about using atomic_t?

Note, my latest code doesn't have any of this, but I just want to
understand the semantics of these operations a bit better.

Nope, atomic_t doesn't help here either. Atomics only make sure the RmW
cycle is atomic.

Note that even if wmb or mb did flush the store buffer, you would still
have a race here.