<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:52:40 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[YANGTOOLS-241] Remove double-checked locking in ReadOnlyTrieMap</title>
                <link>https://jira.opendaylight.org/browse/YANGTOOLS-241</link>
                <project id="10188" key="YANGTOOLS">yangtools</project>
                    <description>&lt;p&gt;ReadOnlyTrieMap uses the double-checked locking (DCL) technique in this method:&lt;/p&gt;

&lt;p&gt;    protected Map&amp;lt;K, V&amp;gt; delegate() {&lt;br/&gt;
        if (readOnly == null) {&lt;br/&gt;
            synchronized (this) {&lt;br/&gt;
                if (readOnly == null) &lt;/p&gt;
{
                    readOnly = readWrite.readOnlySnapshot();
                }
&lt;p&gt;            }&lt;br/&gt;
        }&lt;/p&gt;

&lt;p&gt;        return readOnly;&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;However DCL is not thread-safe. See &lt;a href=&quot;http://www.javaworld.com/article/2074979/java-concurrency/double-checked-locking--clever--but-broken.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.javaworld.com/article/2074979/java-concurrency/double-checked-locking--clever--but-broken.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;A few solutions:&lt;/p&gt;

&lt;p&gt;1) The simplest solution is to avoid lazy initialization and created readOnly in   &lt;br/&gt;
   the ctor and make it final. &lt;/p&gt;

&lt;p&gt;2) If we really want lazy initialization the remove the DCL:&lt;/p&gt;

&lt;p&gt;    protected Map&amp;lt;K, V&amp;gt; delegate() {&lt;br/&gt;
        synchronized (this) {&lt;br/&gt;
            if (readOnly == null) &lt;/p&gt;
{
                readOnly = readWrite.readOnlySnapshot();
            }
&lt;p&gt;        }&lt;/p&gt;

&lt;p&gt;        return readOnly;&lt;br/&gt;
    }&lt;/p&gt;

&lt;p&gt;    The downside to synchronizing on &apos;this&apos; is that users may also synchronize &lt;br/&gt;
    on the instance externally resulting in unwanted contention.&lt;/p&gt;

&lt;p&gt;3) Keep the lazy initialization and DCL but make readOnly volatile. However this &lt;br/&gt;
   would only be safe if readOnly is immutable (all fields final) or has all its &lt;br/&gt;
   fields volatile.&lt;/p&gt;

&lt;p&gt;DCL is usually not worth the trouble. Depending on usage, ie we can assume users will call delegate most of the time, I would opt for #1. Otherwise #2.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="22661">YANGTOOLS-241</key>
            <summary>Remove double-checked locking in ReadOnlyTrieMap</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10000">Done</resolution>
                                        <assignee username="rovarga">Robert Varga</assignee>
                                    <reporter username="tpantelis">Tom Pantelis</reporter>
                        <labels>
                    </labels>
                <created>Thu, 31 Jul 2014 15:59:41 +0000</created>
                <updated>Sun, 10 Apr 2022 18:35:13 +0000</updated>
                            <resolved>Mon, 4 Aug 2014 07:41:48 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>2</watches>
                                                                                                                <comments>
                            <comment id="42901" author="rovarga" created="Fri, 1 Aug 2014 08:42:27 +0000"  >&lt;p&gt;Valid comment, although the bad effects of possible compiler optimization are limited to increased cpu/memory usage.&lt;/p&gt;

&lt;p&gt;Taking the snapshot affects performance on subsequent operations on the backing map, so we do not want to instantiate it unless absolutely necessary.&lt;/p&gt;

&lt;p&gt;DCL is needed because accessing the snapshot is on perf-critical path, so we want to elide locking as much as possible.&lt;/p&gt;

&lt;p&gt;Finally this is a class which has a lot of instances, so an internal lock has prohibitive cost, especially since none of the current users synchronize on these objects.&lt;/p&gt;

&lt;p&gt;The data in the snapshot is logically immutable, so option #3 it is: &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/9567/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/9567/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="42902" author="tpantelis" created="Fri, 1 Aug 2014 12:20:13 +0000"  >&lt;p&gt;That article I linked to says volatile may not fix it but that contradicts other articles I&apos;ve read that say volatile does fix it (e.g. &lt;a href=&quot;http://jeremymanson.blogspot.com/2008/05/double-checked-locking.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://jeremymanson.blogspot.com/2008/05/double-checked-locking.html&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;I turns out that article is older (looks like from 2001) prior to java 1.5 where volatile&apos;s semantics were vague. With the revised, clearly-defined semantics for volatile in the newer 1.5 JMM, volatile is now safe to use for DCL (in fact I remember reading that they specifically defined volatile semantics to make DCL work).&lt;/p&gt;</comment>
                            <comment id="42903" author="tpantelis" created="Fri, 1 Aug 2014 13:04:01 +0000"  >&lt;p&gt;Ok - the semantic they added in JMM 1.5 that makes volatile safe for DCL is that non-volatile writes (and non-final) occurring before a volatile (or final) write cannot be re-ordered after it (although non-volatile writes occurring after can be re-ordered before it). Same for reads. So, for DCL, any non-volatile and non-final writes in the constructor are guaranteed to be visible to all threads b/c they cannot be moved after the volatile write of the DCL variable. &lt;/p&gt;

&lt;p&gt;(In reply to Tom Pantelis from comment #2)&lt;br/&gt;
&amp;gt; That article I linked to says volatile may not fix it but that contradicts&lt;br/&gt;
&amp;gt; other articles I&apos;ve read that say volatile does fix it (e.g.&lt;br/&gt;
&amp;gt; &lt;a href=&quot;http://jeremymanson.blogspot.com/2008/05/double-checked-locking.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://jeremymanson.blogspot.com/2008/05/double-checked-locking.html&lt;/a&gt;).&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I turns out that article is older (looks like from 2001) prior to java 1.5&lt;br/&gt;
&amp;gt; where volatile&apos;s semantics were vague. With the revised, clearly-defined&lt;br/&gt;
&amp;gt; semantics for volatile in the newer 1.5 JMM, volatile is now safe to use for&lt;br/&gt;
&amp;gt; DCL (in fact I remember reading that they specifically defined volatile&lt;br/&gt;
&amp;gt; semantics to make DCL work).&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1460</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=1460]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10202" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Priority</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10312"><![CDATA[High]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i0260f:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>