[jmm-dev] jdk9 APIs [Fences specifically]

[Paul E. McKenney]

On Fri, Aug 14, 2015 at 11:36:55AM -0700, Hans Boehm wrote:
> On Fri, Aug 14, 2015 at 4:50 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> > 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.
> I think it's not a limitation; it's just the wrong mechanism.
> The mechanism you want doesn't care about reordering of
> memory visibility to other threads.  That's what fences are
> about.  It does care about merging of memory operations and
> reordering with local compute operations.  Fences are not about that.
> As you point out, that's kind of the domain of C-style volatiles,
> though they really only address the "combining" part.
> 
> >
> [Hans:]
> >>  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".
> I think the RCU constraint is about ordering.  It's not "really read this".
> CSE on two consume loads is OK for correctness, though
> probably otherwise evil.  And my understanding is that
> you really want to order loads with respect to dependent stores
> as well.

Indeed, if the code faces severe response-time constraints, its developers
and users won't thank you for common subexpression elimination on a
pair of consume loads (even assuming that the users are in a position to
express any opinion at all after the dust settles).  However, it could
actually be a very good thing if the code had throughput and scalability
requirements, but no pressing response-time requirements.

As you no doubt guessed, given current C and C++ compilers, my
recommendation would be to mark respond-time-constrained consume loads
as "volatile", unpopular though that recommendation appears to be in
many quarters.  ;-)

							Thanx, Paul