Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double-Checked Locking #488

Open
QiAnXinCodeSafe opened this issue Sep 16, 2020 · 1 comment
Open

Double-Checked Locking #488

QiAnXinCodeSafe opened this issue Sep 16, 2020 · 1 comment

Comments

@QiAnXinCodeSafe
Copy link

if(schema == null) {
synchronized (discoveredSchemas) {
schema = discoveredSchemas.get(schemaName);
if (schema == null) {
schema = new HollowDiscoveredSchema(schemaName, type, listSubType);

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants