You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pr@jena.apache.org by GitBox <gi...@apache.org> on 2020/03/15 15:56:42 UTC

[GitHub] [jena] afs edited a comment on issue #709: Add volatile to make method thread-safe

afs edited a comment on issue #709: Add volatile to make method thread-safe
URL: https://github.com/apache/jena/pull/709#issuecomment-599228455
 
 
   I'm not a JMM expert either - it's good to thrash out the details. We both learn - the code is better. Unit testing concurrent code is insufficient - thinking and talking about concurrent code is needed.
   
   > The thread 2 then may still not see a completely initialized Set.
   
   meaning the set object from thread 1 is not visible properly yet? OK - I can see that now.
   
   Making `acceptedParams_` volatile puts in a happens-before point (write to a volatile). 
   I was hoping to avoid a volatile - more a style thing, the code is trying to create an immutable object while allowing `fusekiParams()` or `customParams()` to be overridden. That's feature not currently used but is there to allow additional params to be added by customizations.
   
   The fact that two objects can be created does not matter. If thread 1 creates a set, and uses it, and thread 2 sees null still, creates its own object and uses it, eventually overwriting `acceptedParams_` is not a problem (it is always the same set contents).
   
   Is there a better way to achieve subclass overrides to provide `customParams()`? If it weren't for that, everything could be done in class statics.
   
   Otherwise, volatile it is.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscribe@jena.apache.org
For additional commands, e-mail: pr-help@jena.apache.org