Date: Wed, 26 Sep 2012 11:14:41 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-hackers <freebsd-hackers@FreeBSD.org> Subject: monitor+mwait and volatile-ish Message-ID: <5062B971.30203@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5062B971.30203>