java - Why SafePoint class from concurrency in practice book marked as @ThreadSafe?

Question

In the Java Concurrency in Practice book you can find following code:

@ThreadSafe
public class SafePoint { 
    @GuardedBy("this") private int x, y;
    private SafePoint(int[] a) { this(a[0], a[1]); }
    public SafePoint(SafePoint p) { this(p.get()); }
    public SafePoint(int x, int y) { 
        this.x = x;
        this.y = y;
    }
    public synchronized int[] get() { return new int[] { x, y };
    }
    public synchronized void set(int x, int y) { this.x = x;
        this.y = y;
    }
}

This marked as @ThreadSafe.

I am pretty sure that this class is not thread-safe (if I understand this term correctly).

Example:

 SafePoint racePublishedSafePoint; // field

 // thread 1:
 racePublishedSafePoint = new SafePoint(1,1);

 // thread 2:
 SafePoint sp;
 while(true){
   SafePoint sp = racePublishedSafePoint;
   if(sp != null) break;
 }
 System.out.println(sp.get()[0]);
 System.out.println(sp.get()[1]);

I believe that there is several possible outcomes:

1. The application doesn't finish
   else
2. If application finished, we can see
   a) 0 0
   b) 0 1
   c) 1 0
   d) 1 1

Am I right?

If true, why did the author mark the class as thread safe? I thought that thread-safe class - class which can be used in concurrent application without sophisticated analysis.

What did author want to say?

P.S.

I have read the Private constructor to avoid race condition

...and my topic is not duplicate.

Answer 1

I agree with the OP that the example seems to violate the usual understanding of @ThreadSafe guarantees. The unsafe publication races are very real, and of course you can see puzzling behaviors when publishing SafePoint via the race. Some real-life thread-safe classes survive racy publication (String being a notorious example of this), adding up to the confusion.

As far as JCIP narrative goes, I have no paper or electronic copy handy, so reached out to Doug Lea (one of the primary authors), who said:

I think the part of confusion is in the JCIP text. I don't think @ThreadSafe covers publication races, or any other races that could be encountered during construction. Publication safety is treated separately.

Still, I can see how people could think otherwise. It is one of the reasons for us exploring always placing release fences in constructors.

The last part Doug is talking about is briefly described in "All Fields Are Final", including the motivation, experimental patches, and performance estimates.