State ownership cover everything for a class to be thread safe

Question

As mentioned by Java_author,

When defining which variables form an object's state, we want to consider only the data that object owns....

In many case, ownership and encapsulation go together— the object encapsulates the state it owns and owns the state it encapsulates....

A class usually does not own the objects passed to its methods or constructors, unless the method is designed to explicitly transfer ownership of objects passed in (such as the synchronized collection wrapper factory methods)...

---

For ensuring thread safety, a non-thread-safe class need to draw a line on the state variables that it owns to ensure thread safety. Those state variables can be populated in class through generalization, association, Dependency Injection and what not.

My understanding is, Java author already gave(above) a parameter to assess state ownership for thread safety, the object encapsulates the state it owns and owns the state it encapsulates

Edit after this comment:

Below code taken from Listing 4.4/4.5 by Java_author, See the MonitorVehicleTracker class below owning locations that are populated thru copy constructor,

package responsive;

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

class MutablePoint{
    public int x, y;
    
    public MutablePoint() {
        x=0; y=0;
    }
    
    public MutablePoint(MutablePoint p) {
        this.x = p.x;
        this.y = p.y;
    }
}

public class MonitorVehicleTracker {

    private final Map<String, MutablePoint> locations;
        
    public MonitorVehicleTracker( // Copy constructor
                        Map<String,MutablePoint> locations) {
        this.locations = deepCopy(locations);
        
    }
    
    public synchronized Map<String, MutablePoint> getLocations(){
        return deepCopy(locations);
    }
    
    public synchronized MutablePoint getLocation(String id) {
        
        MutablePoint loc = locations.get(id);
        return loc == null ? null : new MutablePoint(loc);
    }
    
    public synchronized void setLocation(String id, int x, int y) {
        MutablePoint loc = locations.get(id);
        if(loc == null) {
            throw new IllegalArgumentException("No such id: " + id);
        }
        loc.x = x;
        loc.y = y;
    }
    
    
    private static Map<String, MutablePoint> deepCopy(
            Map<String, MutablePoint> m){
        
        Map<String, MutablePoint> result = 
                    new HashMap<String, MutablePoint>();
        
        for(String id: m.keySet()) {
            result.put(id, new MutablePoint(m.get(id)));
        }
        
        return Collections.unmodifiableMap(result);
    }
    

}

that is used by GUI thread,

Map<String, Point> location = vehicles.getLocations();
for(String key: locations.keySet()){
   renderVehicle(key, locations.get)key));
}

and used by updater thread,

void vehicleMoved(VehicleMovedEvt evt){
   Point loc = evt.getNewLocation();
   vehicles.setLocations(evt.getVehicleId(), loc.x, loc.y);
}

---

For a non-thread-safe class to make thread-safe,

Do you agree with this parameter to apply synchronization policy on only those state variables that you own to ensure thread safety?

Answer 1

Don't over-conflate ownership with thread safety. To make a class threadsafe, you have to make it threatsafe. No more. No less. This means:

• You cannot have two threads write to the same data at the same time
• You cannot have one thread write to the data and one thread read from it at the same time.
• The synchronization you add to the class does not violate any of the invariants of its methods (such as any guarantees of determinism).

Now it happens to be that encapsulation and ownership draw hard lines in the sand, and it can be easier to implement said threadsafety if you leverage these existing lines. As an example, one of the concerns in making multithreaded code is deadlocks, where two threads contend for two locks in a way that prevents either from making progress. If you put your synchronization at the edge of the encapsulated data, it becomes easy to prove that a particular class is deadlock free.

But ownership can't cover everything. Consider that ownership means you can do anything you want with the data. Read it, write it, store temporary copies of it. It's yours. In many multithreaded situations, you want many threads to be able to read the data simultaniously. In order to do this, the "owner" must give up the right to write to that data until the reads are complete. Generally speaking, our concept of "ownership" is not subtle enough to draw distinctions like this.

Answer 2

Yes, objects formed via composition own the data objects they are composed of generally. That in itself does not ensure thread safety, though. There are a few reasons:

1. The same object could be called on multiple threads, so it may actually make its own state inconsistent if you don't take proper precautions (such as using a mutex or similar construct)
2. If Object A owns Object B, but Object C asks for a reference rather than a copy of Object B, then both A & C may be able to modify Object B if you aren't careful.

You also ask:

For code:

class MyClass { 
    private HashSet<Person> mySet = new HashSet<Person>(); 
    private int x;
}

Does object's state ownership involve just x, and mySet or state ownership involves x, mySet and Person? Here, MyClass has composition relationship with HashSet.

I would say that MyClass owns mySet and x and that mySet owns each Person it contains. (So transitively MyClass also owns each Person.) This is all assuming that nobody else has strong references to these objects. (And in general only one object should ever have a strong reference to a given object.)