[jira] [Updated] (GEODE-3774) Remove double-checked Locking in New Client Protocol code

["Galen O'Sullivan (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galen O'Sullivan updated GEODE-3774:
------------------------------------
    Description: 
{{ServerConnectionFactory}} uses double-checked locking for loading the services it depends on.

It's probably looking at where else we may use this idiom, as it's fundamentally broken.
Marking the field that's locked this way {{volatile}} may not resolve the issue, as the object itself could be read as uninitialized even if the field (reference) isn't. I don't really know the JMM well enough to be sure that it's broken, but that's a good sign that we shouldn't do it unless we really need to for performance reasons (and even then...)

This may be best to resolve after GEODE-3751 and GEODE-3739 due to the changes to loading those refactors will bring.

While we're at it, we should assert that there is only one client protocol service, because we can't handle to and which one we choose is undefined.

  was:
It's probably looking at where else we may use this idiom, as it's generally broken.

This may be best to resolve after GEODE-3751 and GEODE-3739 due to the changes to loading those refactors will bring.


> Remove double-checked Locking in New Client Protocol code
> ---------------------------------------------------------
>
>                 Key: GEODE-3774
>                 URL: https://issues.apache.org/jira/browse/GEODE-3774
>             Project: Geode
>          Issue Type: Bug
>          Components: client/server
>            Reporter: Galen O'Sullivan
>
> {{ServerConnectionFactory}} uses double-checked locking for loading the services it depends on.
> It's probably looking at where else we may use this idiom, as it's fundamentally broken.
> Marking the field that's locked this way {{volatile}} may not resolve the issue, as the object itself could be read as uninitialized even if the field (reference) isn't. I don't really know the JMM well enough to be sure that it's broken, but that's a good sign that we shouldn't do it unless we really need to for performance reasons (and even then...)
> This may be best to resolve after GEODE-3751 and GEODE-3739 due to the changes to loading those refactors will bring.
> While we're at it, we should assert that there is only one client protocol service, because we can't handle to and which one we choose is undefined.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)