monitor+mwait and volatile-ish

Andriy Gapon avg at FreeBSD.org
Wed Sep 26 08:14:52 UTC 2012


Typical x86 MONITOR+MWAIT is like this (taken from Intel manual):

EAX = Logical Address(Trigger)
ECX = 0 (*Hints *)
EDX = 0 (* Hints *)
IF ( !trigger_store_happened) {
	MONITOR EAX, ECX, EDX
	IF ( !trigger_store_happened ) {
	MWAIT EAX, ECX
	}
}

In FreeBSD we have this helper function for MONITOR:
static __inline void
cpu_monitor(const void *addr, u_long extensions, u_int hints)
{

        __asm __volatile("monitor"
            : : "a" (addr), "c" (extensions), "d" (hints));
}

Now, let's assume that 'Trigger' is a global variable and
'trigger_store_happened' is a check for a particular value in this variable.

Then, with current state of matters, we must either declare the global variable
to be volatile or use a volatile cast in the second IF.  Otherwise, a compiler
is free to assume that the variable doesn't change between the first and the
second IF and drop the second IF altogether.  And that would make MONITOR+MWAIT
to miss an event if it happens "between" the first check and MONITOR.

So what's my point.
- using volatile variable with cpu_monitor requires DEVOLATILE to silence
compiler warning about discarding volatile; this is unnecessary code bloat
- adding volatile cast in the checks is easy to forget and adds code bloat

Possible improvements:
- make the argument of cpu_monitor be 'const volatile void *', the most
permissive type; this would also be a hint that variable should be volatile
- add some magic dust to cpu_monitor that would tell compiler to not cache
  the variable; right now I can only think of the "memory" constraint, but it
  seems to be too big of a hummer

What do you think about this?

-- 
Andriy Gapon


More information about the freebsd-hackers mailing list