<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 19:53:42 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>[CONTROLLER-722] ShardWriteTransaction needs to synchronize access to its SnapshotBackedWriteTransaction</title>
                <link>https://jira.opendaylight.org/browse/CONTROLLER-722</link>
                <project id="10113" key="CONTROLLER">controller</project>
                    <description>&lt;p&gt;The SnapshotBackedWriteTransaction has no internal synchronization and thus is not safe for multiple-thread access, concurrent or not. This is the intention for performance reasons - let the client synchronize it if they need to (like the JDK collections classes do).&lt;/p&gt;

&lt;p&gt;ShardWriteTransaction actor receives write/merge/delete/ready messages via akka and, internally, it has a SnapshotBackedWriteTransaction that each message modifies. While messages are not sent concurrently by akka and updates in the SnapshotBackedWriteTransaction will not occur concurrently, they may be sent serially by multiple akka threads. &lt;/p&gt;

&lt;p&gt;One aspect of multi-threading in java and the java memory model is ensuring that writes done one thread are published or made visible to other threads. This requires some form of synchronization (i.e. synchronized block, java.concurrent.Lock, volatile keyword, final keyword on instance fields, thread enter/exit ...).&lt;/p&gt;

&lt;p&gt;We could simply synchronize on the SnapshotBackedWriteTransaction instance but this carries the exclusive lock overhead that we don&apos;t need as we won&apos;t have concurrent access. Instead, we could use a separate volatile variable as a read/write memory barrier &quot;guard&quot; for publishing writes across threads, as explained here by this snippet in Java Concurrency in Practice: &lt;/p&gt;

&lt;p&gt;&quot;The visibility effects of volatile variables extend beyond the value of the volatile variable itself. When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to the volatile variable become visible to B after reading the volatile variable.&quot;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="25276">CONTROLLER-722</key>
            <summary>ShardWriteTransaction needs to synchronize access to its SnapshotBackedWriteTransaction</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="10003">Cannot Reproduce</resolution>
                                        <assignee username="tpantelis">Tom Pantelis</assignee>
                                    <reporter username="tpantelis">Tom Pantelis</reporter>
                        <labels>
                    </labels>
                <created>Sat, 23 Aug 2014 13:27:19 +0000</created>
                <updated>Sun, 24 Aug 2014 00:10:43 +0000</updated>
                            <resolved>Sun, 24 Aug 2014 00:10:43 +0000</resolved>
                                    <version>Helium</version>
                                                    <component>mdsal</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>3</watches>
                                                                                                                <comments>
                            <comment id="48951" author="tpantelis" created="Sun, 24 Aug 2014 00:10:43 +0000"  >&lt;p&gt;In reading akka&apos;s documentation, specifically &lt;a href=&quot;http://doc.akka.io/docs/akka/snapshot/general/jmm.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://doc.akka.io/docs/akka/snapshot/general/jmm.html&lt;/a&gt;, akka defines the following happens-before rule:&lt;/p&gt;

&lt;p&gt;  &quot;The actor subsequent processing rule: processing of one message happens before processing of the next message by the same actor.&quot;&lt;/p&gt;

&lt;p&gt;&quot;This means that changes to internal fields of the actor are visible when the next message is processed by that actor. So fields in your actor need not be volatile or equivalent.&quot; &lt;/p&gt;

&lt;p&gt;So akka takes care of synchronization of actor internal state between messages. Makes sense as akka&apos;s main premise is to &quot;alleviate the developer from having to deal with explicit locking and thread management&quot;.&lt;/p&gt;

&lt;p&gt;This bug is not needed - closing.&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>1609</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=1609]]></customfieldvalue>

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

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