On 17/10/17 14:00, David Brown wrote:
> So how do you implement these macros in a way that is efficient,
> correct, and safe to use? Including memory barriers in the form of
> memory clobbers certainly helps, though it can mean less optimal code -
> give the "normal" users sub-optimal but ease and safe macros, and let
> the advanced (or obsessive!) users fix the dependencies themselves. But
> as we have seen, memory barriers are not necessarily enough. There is
> no "execution barrier".
Indeed, yes, you'd want a way to insert an opaque barrier to GCC's
optimization horizon (i.e. how far GCC can see.) But that is an
extremely violent thing to do, effectively even more than a memory
clobber.
In a way, I think that you're asking for something self-contradictory.
If you want a full execution barrier, you'll have to force all
calculations to complete before ENTER_CRITICAL(), even those you don't
need.
I think it would be possible to write versions of ENTER_CRITICAL() and
EXIT_CRITICAL() which take arguments, and these would be the values
which must be stable at these points. You could do that with current
GCC with asm("" : "+r"(bar), "+r"(baz));. But there's still nothing
to stop GCC from doing anything unrelated during the time that
interrupts are disabled. If you really need that guarantee, a
noinline function is the only way I know to get it done.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
