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

Make lazy initialization of static Val.Obj thread-safe #136

Merged
merged 1 commit into from
Nov 30, 2021

Conversation

szeiger
Copy link
Collaborator

@szeiger szeiger commented Nov 3, 2021

Static Val.Obj instances are created by the optimizer and will end up in the parse cache. If the cache is shared by multiple threads, initialization must be sufficiently safe, i.e. computing a value multiple times in race conditions is allowed (and cheaper than ensuring that it doesn't happen), but object must never get into an invalid intermediate state.

@@ -155,10 +155,11 @@ object Val{

private[this] def getValue0: util.LinkedHashMap[String, Obj.Member] = {
if(value0 == null) {
value0 = new java.util.LinkedHashMap[String, Val.Obj.Member]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment explaining why we do things in this way, and the multi-threaded guarantee we want to maintain?

Static Val.Obj instances are created by the optimizer and will end up in the parse cache. If the cache is shared by multiple threads, initialization must be sufficiently safe, i.e. computing a value multiple times in race conditions is allowed (and cheaper than ensuring that it doesn't happen), but object must never get into an invalid intermediate state.
@szeiger szeiger merged commit 541b00b into databricks:master Nov 30, 2021
jam01 pushed a commit to jam01/sjsonnet that referenced this pull request Mar 7, 2022
Static Val.Obj instances are created by the optimizer and will end up in the parse cache. If the cache is shared by multiple threads, initialization must be sufficiently safe, i.e. computing a value multiple times in race conditions is allowed (and cheaper than ensuring that it doesn't happen), but object must never get into an invalid intermediate state.
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

Successfully merging this pull request may close these issues.

3 participants