[jmm-dev] Sequential Consistency

[Paul E. McKenney]

On Mon, Feb 24, 2014 at 08:00:08AM -0500, Doug Lea wrote:
> On 02/24/2014 01:52 AM, Hans Boehm wrote:
> >I think it's that last comment here that needs to be emphasized: We don't really
> >have a viable candidate property to replace SC, that's anywhere near as easy to
> >reason about and provides significant performance advantages. Several people,
> >including Doug, looked hard for such things when we were talking about  C++.
> 
> Yes (plus similar explorations for X10, and distributed consistency).
> We are pretty sure that there is no good substitute for requiring
> SC for lock-based programs. I think the main issue at hand is
> how far SC applies. We cannot require SC for all uses of
> mode-based/fenced/volatile accesses, because some sets of
> usages clearly are not SC. The audience of people using them
> seem happy to rely only on specs of ordering constraints.
> So it may suffice to just leave it at that. Although people
> do need to know which usages are emergently SC, so that they
> can for example build locks, which may require some special
> care in specification.
> 
> This is just a slightly different perspective on similar issues
> and decisions in C/C++11.  Among the differences is that we
> have "legacy" mode-less default volatile load/store, for
> which it is not clear that requiring uniform SC guarantees
> (versus only for get/set Sequential) would be doing anyone
> a favor. And not clear that it wouldn't.

Even I have come to grudgingly accept that SC is a reasonable default.
But I definitely would not want to give up weaker modes.  Something
about needing my code to perform and scale well.  ;-)

> While I'm at it...
> 
> >On Sun, Feb 23, 2014 at 5:59 AM, Doug Lea <dl at cs.oswego.edu
> ><mailto:dl at cs.oswego.edu>> wrote:
> >
> >    The IRIW example is a fun one in part because it is not especially
> >    intuitive.  Some people do not at first think that it is a result
> >    forced by SC. I occasionally present this in courses, and most
> >    students' first reaction is that you should use a common lock in all
> >    threads if you want to ensure agreement about order of x and y
> >    here. The fact that you don't need to strikes some (but by no means
> >    all) people as a magical/spooky property of SC.
> 
> A caveat: When I've done this in courses, there's usually
> some student who tries to exploit this to avoid locks/sync
> in some programming project. But never correctly -- the example
> does not seem to generalize in any useful way. In fact, I have
> never seen a program where SC-IRIW matters, so arguably,
> most people are better off not even knowing about it :-)

I heard a rumor that some work-stealing task scheduler relied on SC-IRIW,
but never have been able to track it down.  Even if someone does track
it down, I would argue that it is the exception that proves the rule.  ;-)

							Thanx, Paul