[jmm-dev] jdk9 APIs [Fences specifically]
Paul E. McKenney
paulmck at linux.vnet.ibm.com
Fri Aug 14 19:09:07 UTC 2015
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.
> >> 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. ;-)
More information about the jmm-dev