On Jul 30, 2012, at 2:10 PM, sebb wrote: > On 30 July 2012 20:34, Oliver Heger <oliver.he...@oliver-heger.de> wrote: >> Am 29.07.2012 22:41, schrieb Ralph Goers: >> >>> I used that specifically to avoid creating multiple combined >>> configurations since it can be fairly expensive to create them. I looked >>> into the guarantees that ConcurrentMap provides before I implemented that >>> and included the comment since I knew it would catch someone's eye. >>> >>> Ralph >> >> >> Thanks for clarifying. I added a suppression in the Checkstyle configuration >> so that this warning will not pop up again. > > An alternative solution might be to drop the synchronised block and > use the atomic putIfAbsent() method. > > That would reduce the synch. overhead. > The downside is that the code might occasionally create and configure > an instance of CombinedConfiguration that is then not used (if another > thread happens to do the same).
Did you read Oliver's message which is directly below what you wrote? Ralph > >> Oliver >> >> >>> >>> On Jul 29, 2012, at 12:40 PM, Oliver Heger wrote: >>> >>>> There is a checkstyle warning about double-checked locking in method >>>> DynamicCombinedConfiguration.getCurrentConfig(). Indeed, the double-check >>>> locking idiom is used, however, there is a comment saying that this safe >>>> due >>>> to the usage of a ConcurrentMap. >>>> >>>> This may be true, but I wonder whether it would be better to use the >>>> map's putIfAbsent() method and avoid synchronization. The worst thing that >>>> can happen is that on parallel access multiple CombinedConfiguration >>>> instances are created which can be passed immediately to the garbage >>>> collector. >>>> >>>> Thoughts? >>>> >>>> Oliver >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
