[concurrency-interest] ConcurrentMapconsistencyrequirementsconfusion

Boehm, Hans hans.boehm at hp.com
Sun Dec 11 01:01:20 EST 2011

> From: David Holmes [mailto:davidcholmes at aapt.net.au]
> Hans Boehm writes:
> > Are current implementations strong
> > enough to make that correct?  If I encode Dekker's using CHMs, as
> > in ("key" entries initially "0"):
> >
> > Thread 1:
> > a.put("key","1");
> > r1 = b.get("key");
> >
> > Thread 2:
> > b.put("key","1");
> > r2 = a.get("key");
> >
> > Can I get r1 = r2 = "0"?  Presumably not.
> I would say you definitely should not else there is a significant bug
> in the
> implementation.
> But I fear this discussion is degenerating into the usual JMM chaos.
> Nothing
> is guaranteed, nothing is provable so we might as well quit programming
> and
> go home. ;-)
> David
> -----
I guess I'm more positive than you about the Java memory model.  My view is that in the absence of data races, i.e. for well-synchronized code, the Java memory model is well-defined and easy to use: It's sequential consistency.  The 2005 revision clarified that, and that part is perfectly sound and extremely useful.  Beyond that, there are a few statements we can make about racy programs, particularly in conjunction with final fields, but mostly I do think things are in need of repair.  But, aside from situations in which you need to tolerate sandboxed malicious code, or get the last few percent in performance, you can stay in the data-race-free subset, and life is good.

I think the questions we were addressing here all have to do with the race-free part, which is basically in good shape.  And I think you've confirmed that CHM plays by the intended rules.  I still don't think this is stated very well in the spec, but the intent seems to be that CHM get and put operations play by essentially the same rules as volatile variable accesses.  And I think the implementation is such that they do.  (It sounds like the implementation itself is also data-race-free, so it automatically has the right properties?)  All of that is good.  The documentation could be improved, but I think every concurrency library currently has similar issues.  You can find similar discussions on the C++ committee mailing list.

The JMM, I think with the sole exception of 17.4.9, gives you only partial correctness guarantees; it only promises what happens if your program finishes, not whether it does.  17.4.9 gives only very weak (and hard-to-decipher) progress guarantees.  When you ask questions about progress, you shouldn't expect too much of an answer from the JMM.  As I said earlier, that was by design, though it may need to be revisited at some point.


More information about the Concurrency-interest mailing list