Double-Checked Locking

[QiAnXinCodeSafe]

https://github.com/Netflix/hollow/blob/7ff25c9b3113d731341ca203ee81a46d7ab46cdc/hollow-jsonadapter/src/main/java/com/netflix/hollow/jsonadapter/discover/HollowJsonAdapterSchemaDiscoverer.java#L191-L195

double-Checked Locking is widely cited and used as an efficient method for implementing lazy initialization in a multithreaded environment. Unfortunately, it will not work reliably in a platform independent way when implemented in Java, without additional synchronization.

[clay-mayers]

The above looks like you've quoted this article: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.

I don't see an issue here. This is my understanding. The idiom used there is not the same as what is used by Hollow. The article is about "just-in-time" construction of a member object being read without "synchronization" (i.e., barrier or lock of some sort). The Hollow code is constructing an object read from a ConcurrentHashMap, which is "synchronized" (not by the keyword necessarily but by the use of a barrier or lock). An update has a happens-before relation with get so all writes before the update (i.e. the construction of schema) will be visible to whoever called get.

What's inside the synchronized block is only there to construct a single schema. If that were not there, the only consequence would be two constructed schema's instead of one, not a data inconsistency issue.

Looking past the "double-checked" idiom critique, underneath is the general issue of making a constructed object visible to multiple threads before the writes of that object are fully visible. This applies to discoveredSchemas, but that already has the "additional synchronization" because it is declared final. That ensures all threads see the fully constructed Map<>.

I think this a correct analysis - if not, please be more specific on what the issue is.