Hans' assessment seems about right in the generic case he's describing.
But consider:
1. There is no concurrent setting of anything here - it's done in a
static initializer which will happen exactly once by the thread
initializing the class ($ 12.2.4 item 9).
2. While there is a data race on the access of the fields in
SharedSecrets, all of the Access instances are stateless. This means the
race is benign in the sense that when reading the field only a null or
a safely published instance can be observed.
I wouldn't swear there's a strict guarantee a null can never be returned
from a SharedSecrets accessor though. Perhaps that's something that
could be hardened.
/Claes
On 2020-12-30 00:32, some-java-user-99206970363698485...@vodafonemail.de
wrote:
That would also be my understanding of the current situation, though
this contradicts what
Claes wrote.
Maybe the JVM behaves in a way which does not allow reordering, but the
JLS definitely seems
to allow it. Section ยง 12.2.4 [0] only mentions that for the class to be
initialized there
has to exist a lock LC (or at least the happens-before relationship),
but there is no
"freeze the world" or anything similar which would force a
happens-before relationship
for the code in `SharedSecrets`.
Maybe most of the `SharedSecrets` methods are thread-safe (albeit
extremely brittle) because
the classes to which the accessor objects belong to have previously
already been loaded
before `SharedSecrets` is used, therefore having already established a
happens-before
relationship.
However, this is definitely not the case for all of the methods as shown
by the following
example:
```
CookieHandler.setDefault(new CookieHandler() {
@Override
public void put(URI uri, Map<String, List<String>> responseHeaders)
throws IOException { }
@Override
public Map<String, List<String>> get(URI uri, Map<String,
List<String>> requestHeaders) throws IOException {
return Collections.emptyMap();
}
});
// Any site which uses cookies (i.e. Set-Cookie or Set-Cookie2 header)
URL url = new URL("https://oracle.com";);
url.openConnection().getHeaderFields();
```
Running this code with `openjdk 15 2020-09-15` shows that the call to
`SharedSecrets.getJavaNetHttpCookieAccess()` is made before the class
`HttpCookie` has
been accessed and initialized. Therefore merely running this code in two
separate threads
(both having been started before the code is executed, since
`Thread.start()` establishes
a happens-before relationship) should be enough to render that
`SharedSecrets` method
non-thread-safe.
Kind regards
[0]
https://docs.oracle.com/javase/specs/jls/se15/html/jls-12.html#jls-12.4.2
Hans Boehm <hbo...@google.com> hat am 29. Dezember 2020 um 18:53
geschrieben:
If static_field is not volatile, and set concurrently, then the first
read of static_field may return non-null and the second null, without
initialize() even being executed. The Java memory model does not prevent
reordering of non-volatile reads from the same field (for good reason).
Even if initialize() is executed and performs a volatile read, this
reasoning doesn't hold. The initial static_field read may be delayed past
the volatile read inside the conditional and hence, at least theoretically,
past the second read. Control dependencies don't order reads, either in
Java, or in modern weakly-ordered architectures with branch prediction.
This doesn't matter if initialize() sets static_field.
This all assumes that having two threads call initialize() is OK.
Java code with data races is extremely tricky and rarely correct.
Hans
