ConcurrentHashMap read/update only via compute method

Question

This is basically a continuation of this or this, or many others in that regard.

My question is probably simple, if I use ConcurrentHashMap::compute only, in both readers and writers of some value, is that enough to ensure visibility?

I do know that compute method:

The entire method invocation is performed atomically

Is that enough to guarantee visibility? Specifically, is that true specification/documentation wise with regards to happens-before? To simplify my question, here is an example:

static class State {
    private int age;

    int getAge() {
        return age;
    }

    State setAge(int age) {
        this.age = age;
        return this;
    }
} 

and :

// very simplified, no checks
static class Holder {

    private static final ConcurrentHashMap<String, State> CHM = new ConcurrentHashMap<>();

    public State read(String key) {
        return CHM.compute(key, (x, y) -> y);
    }

    public State write(String key, int age) {
        return CHM.compute(key, (x, y) -> y.setAge(y.getAge() + age));
    }
}

No one has access to CHM and can only work via Holder.

To me the answer is obviously yes, this is safe and all readers will see the result of the latest write method. I just can't connect the dots with the documentation of ConcurrentHashMap, which is most probably obvious, but I seem to miss it.

Answer 1

The compute() javadoc says what this method does:

Attempts to compute a mapping for the specified key and its current mapped value (or null if there is no current mapping).

So compute() replaces a value for the key.

To use compute() to modify the internal fields of some object (even the object is stored as a value in the map) is not what compute() was meant for.
Therefore, naturally, compute()'s specification/documentation guarantees (and even says) nothing about that.

Regarding happens-before, there are multiple mentions in the documentation:

• ConcurrentHashMap:

  More formally, an update operation for a given key bears a happens-before relation with any (non-null) retrieval for that key reporting the updated value.

• ConcurrentMap:

  Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a ConcurrentMap as a key or value happen-before actions subsequent to the access or removal of that object from the ConcurrentMap in another thread.

• java.util.concurrent:

  Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread.

The important thing is that the happen-before relation is only guaranteed between insertion/removal/retrieval of objects to/from the collection.
In your case it is the same State object (only internal its fields are updated), so IMO according to documentation ConcurrentHashMap is even allowed to decide that nothing changed and skip the remaining synchronization steps.

Answer 2

There is happens-before between Holder.read and Holder.write methods obviously. But no any guaranties between State.getAge and Holder.write. if you want to read age you actually need to execute two operations:

(1) State state = holder.read(key);

(2) int age = state.getAge();

So, if Holder.write in another thread happens after (1) but before (2), you may see old age value in (2).