[jmm-dev] jdk9 APIs [Fences specifically]

[Doug Lea]

On 08/13/2015 07:56 PM, Hans Boehm wrote:
> On Thu, Aug 13, 2015 at 4:19 PM, Doug Lea <dl at cs.oswego.edu
>  >
>  > I must be missing something fundamental about C++ specs. Are C++
>  > compilers allowed to ignore release fences in between writes
>  > to the same variables? In unrolled form, that's what this would
>  > amount to here.
>
> I think that's unavoidable.  If I write
>
> for (...) {
>      x = something_expensive();
>      fence;
> }
>
> it's very hard to prevent the implementation from implementing that as
>
> <pause for a while>
> <run the above loop instantaneously and atomically>
>
> And that looks exactly like merging all the stores into one.

In other words, it is legal (at least for some loops in
which you can prove termination etc) to postpone ALL the stores
to end of loop (assuming the CPU has enough registers to
hold them all or is willing to use unbounded local stack space),
in which case even if they are performed in order, you may lose
responsiveness.

So there are limitations in the ability of ordering control to
improve responsiveness. Which is unsurprising given all the
other limitations under weak scheduling guarantees. But
that's not much of an argument for not even allowing it.

>  But I think this doesn't have anything to do with fences.

Ordering constraints seem intrinsic to the problem at hand.
It's the complement of the main issue in  RCU/consume:
"really read this" vs  "really write this".

And like RCU, the construction can be seen as one in which
a special-case optimization removing a processor-level fence
may apply in conditions that are hard to express/control.

You can in the mean time cheat in both cases in C/C++ by
casting to (C) volatile. But nothing like this applies in Java.

-Doug