Memory visibility guarantees provided by intrinsic locking in Java?

Question

I need some clarity on what memory visibility guarantees are provided by using an intrinsic lock in Java.

So for example say if I have a HashMap object that maps Strings to Person objects like so:

HashMap<String,Person> m = new HashMap<String, Person>();

And lets say we have a synchronized method inside the same class like so:

public synchronized void addToMap(String name, Person p){
   m.put(name, p);
}

And also the same class has another synchronized method called get, like so:

public synchronized Person get(String name){
   return m.get(name);
}

So I have two questions.

1

Now lets say Thread A acquires the lock and exectutes the addToMap method., then exits the method and releases the lock.

And then Thread B comes along ,outside the locked method, and changes the state of the Person object that the reference p refers to.

Then, when Thread C acquires the same lock that Thread A had and executes the get() method, is Thread C guaranteed to retrieve the Person object in its most recent state? i.e. after Thread B changed it.

Now this example is highly contrived and if I was using a map with multiple threads then I know I should use ConcurrentHashMap etc, this example is just used to better explain my confusion on visibility guarantees.

I know that when a Thread acquires a lock, it is guaranteed to see any changes that were made to the state of the object from the previous Thread who held that lock, so am I correct in thinking that because Thread B's activity was performed without obtaining the lock, then it is not guaranteed that Thread C will see the changes?

2

Now if my assumption for Question 1 is correct, then lets say Thread B did actually change the state of the Person object that the reference p refers to inside a synchronized method , so it has acquired the lock, then is C guaranteed to see the change that B made? My initial assumption here is that C is guaranteed to see the change that B made, but when I thought about, I am not sure if the actual change, to the Person object p refers to, actually changes the state of the HashMap(which is part of the state of the locked object) as it is not a structural modification like adding or deleting a mapping.

I know that intrinsic locking provides visibility and atomicity guarantees, and volatile variables guarantee only visibility, but my confusion comes on how these guarantees relate to actual Objects(eg the actual Objects in a mapping like the Person object p refers to), rather than just the object references.

Any help to clear this up would be great thanks.

Answer 1

I know that when a Thread acquires a lock, it is guaranteed to see any changes that were made to the state of the object from the previous Thread who held that lock, so am I correct in thinking that because Thread B's activity was performed without obtaining the lock, then it is not guaranteed that Thread C will see the changes?

Yes. Basically, it doesn't matter how you got hold of the object (in this case through a person-reference stored in a map).

Regardless what the thread changes, since it's not holding a lock, it's not part of a happens-before relation, thus subsequent reads are not guaranteed to see the update.

Now if my assumption for Question 1 is correct, then lets say Thread B did actually change the state of the Person object that the reference p refers to inside a synchronized method , so it has acquired the lock, then is C guaranteed to see the change that B made?

If Thread B did hold a lock, and that lock was later acquired by Thread C, then Thread C would see the changes that Thread B made, regardless if the changes were inside a map and so on.

But, it's important to keep in mind that just because you're introducing locks doesn't mean that you don't have data races. Without further synchronization, there's no guarantee that Thread B actually acquires the lock before Thread C.

Hope I understood your question correctly and I hope my answer was clear. Please let me know otherwise.