https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-638 controller <p>With gerrit <a href="https://git.opendaylight.org/gerrit/#/c/9093/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/9093/</a> we unwittingly fixed a concurrency issue with the publicProxies variable. However, the same concurrency issues exist with rpcRouters as well.</p> <p>Basically, we synchronize when we write the the map, but we do not synchronize when we read from it. This can lead to inconsistent behavior in this class.</p> <p>Operating System: Mac OS<br/> Platform: PC</p> CONTROLLER-638

Concurrency issue in RpcProviderRegistryImpl.java

Bug Resolved Done Tony Tkacik Devin Avery Fri, 18 Jul 2014 11:30:21 +0000 Wed, 23 Jul 2014 18:14:53 +0000 Wed, 23 Jul 2014 18:14:53 +0000 Helium mdsal 0 4 <p>Devin, I believe there is not an issue,</p> <p>there is <br/> 1. read, lock, read, write mechanism,<br/> so if unsynchronized read misses, we synchronize and read again<br/> if it miss, create value.</p> <p>Hi Tony -</p> <p>This is actually NOT thread safe for a few reason.</p> <p>1) addRpcImplementation, registerRouterInstantiationListener, method is not synchronized. So even if another thread created the RpcRouter it is not guaranteed to be available in that method.</p> <p>2) The "read, lock, read, write mechanism" is called double-check locking and that is NOT thread safe. See this for the full details: <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html" class="external-link" target="_blank" rel="nofollow noopener">http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html</a>. So for that reason the getRpcService method is not thread safe.</p> <p>I changed this back to a critical bug because concurrency issues are really hard to track down, fix and test. So if we find one we should fix it.</p> <p>Devin is correct. This is a form of DCL which is not thread-safe. There must be synchronization between the writes and the reads in order to guarantee reading threads see the writes.</p> <p>Worse, you could end up with the infamous HashMap endless loop (see <a href="http://confusion.tweakblogs.net/blog/2019/nasty-java-hashmap-race-condition.html" class="external-link" target="_blank" rel="nofollow noopener">http://confusion.tweakblogs.net/blog/2019/nasty-java-hashmap-race-condition.html</a>) if an unsynchronized get or put on one thread happens simultaneous with a put on another thread.</p> <p>Actually the DCL mechanism in this case is OK from a visibility standpoint - if the unsync'ed get returns null, the thread will hit the synchronized block which will result in previous writes by other threads done in that sync block to be visible. However there's likely compiler re-ordering optimizations that could cause issues here.</p> <p>Regardless, the potential for infinite loop in the HashMap is a definite issue. Basically you must synchronize every HashMap operation (get, put, remove etc) or bad things can happen.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/9221/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/9221/</a></p> Development External issue ID 1390 External issue URL ODL SR Target Milestone Rank 0|i02lmv: