How is this class thread safe? (Concurrency in Practice)

I'm reading Concurrency in Practice and I came across this class:

@ThreadSafe
public class PublishingVehicleTracker {
    private final Map<String, SafePoint> locations;
    private final Map<String, SafePoint> unmodifiableMap;

    public PublishingVehicleTracker(Map<String, SafePoint> locations) {
        this.locations = new ConcurrentHashMap<String, SafePoint>(locations);
        this.unmodifiableMap = Collections.unmodifiableMap(this.locations);
    }

    public Map<String, SafePoint> getLocations() {
        return unmodifiableMap;
    }

    public SafePoint getLocation(String id) {
        return locations.get(id);
    }

    public void setLocation(String id, int x, int y) {
        if (!locations.containsKey(id))
            throw new IllegalArgumentException("invalid vehicle name: " + id);
        locations.get(id).set(x, y);
    }
}

My question involves setLocation. I understand it's utilizing a ConcurrentMap, but it's still performing a "check-then-act" operation, which the authors acknowledge (on the following page) is unsafe, event with concurrent collections. This isn't an atomic action. How is this method/class thread safe?

The locations map is read only. There are no operations in the class that add to, or remove elements from the locations map. That leaves the last part of the class where it sets the location.

The setLocation method gets an element from the locations map, and then updates an already existing value in it. That means, if SafePoint.set is thread-safe, the whole class is thread-safe.

Note that this is not a check-then-act situation. It checks if the value is in the map, but then does not modify the map itself, it only modifies the value. There is no way another thread can remove that value from the map, or add another value to the map. So, thread-safety is depending on set being thread-safe.

Most of the time, object is not thread-safe because its state changes are not properly guarded.

Read the following paragraph which I took from "Java Concurrency in Practice" :

> Stateless: it has no fields and references no fields from other classes. The transient state for a particular computation exists solely in local variables that are stored on the thread’s stack and are accessible only to the executing thread. Stateless objects are always thread-safe.

Chapter 2 also shares some ways to make stateful objects thread-safe.

> There are three ways to fix stateful objects:
> - Don’t share the state variable across threads;
> - Make the state variable immutable; or
> - Use synchronization whenever accessing the state variable.

In the above example, locations is a concurrent hashmap, it's a threadsafe collection. unmodifiableMap can't be mutated after initialization. Hence the class is thread-safe.

setLocation is using getLocation(). This is returning an existing entry from locations.

Two differnt threads could call setLocation() in parallel and can call SafePoint.set().
It depends on SafePoint.set() if this is Thread-Safe. If SafePoint.set() needs more time and is not atomic, it can happen while Thread 1 is writing via SafePoint.set() another is intending it, too.

If you can only access to SafePoint via setLocation() you could do it like that:

public void setLocation(String id, int x, int y) {  
   if (!locations.containsKey(id))
       throw new IllegalArgumentException("invalid vehicle name: " + id);
   SafePoint safePoint = locations.get(id);
   synchronized(safePoint){
     safePoint.set(x, y);
   }
}

Every thread calling setLocation will come to the synchronized block. Only one can enter this block.