Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: where's your Vector, victor Date: Sat, 31 May 2014 12:17:41 +0200 Lines: 39 Message-ID: References: <19baa0fb-e0fb-4565-b1eb-44018eb3045d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net JvuU+jWh44xsD2zERHlMhg690aiHnuW1tNgZik4Xgs2Ki3tuI= Cancel-Lock: sha1:Iic3Uw9fROzATdwQVaijKF9nG7o= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:28628 On 31.05.2014 00:23, Eric Sosman wrote: > On 5/30/2014 5:30 PM, Jukka Lahtinen wrote: >> And about the synchronization: in many cases, when you need >> synchronization, you will need to synchronize something more than just >> the Collection manipulation. And if the Collection handling is already >> within a synchronized block, why use one more synchronization block >> inside another one? > > In a multi-threaded setting you need to pay close attention to > exactly which manipulations need to be atomic. Vector or the Lists > produced by Collections.synchronizedList() will guarantee atomicity > for the individual method calls, but (as has been pointed out a few > times already) the program may require some combinations of those to > be atomic. The classic example is iterating over the collection: > Just because .add() and .remove() and so on (and the Iterator methods > themselves) are atomic doesn't imply that the entire iteration is so. > Finally, I question the wisdom of a program design that requires > iterating over a collection shared by multiple threads. There is another effect of synchronization of all Vector methods which has not yet been quoted as far as I can see: because of the Java memory model every entry into and exit from a mutex forms a memory barrier which requires some synchronization (sorry for the term here) between thread local and global memory; it also permits some optimizations of the JRE with regard to reordering operations. So even if each Vector instance is used only inside at most one thread and the overhead of synchronized in the usual simple tests where only a single instance is manipulated in a real world application the synchronization between local and global memory may actually have an adverse effect if many threads are doing a lot of state changes. I would guess that the effect is even worse on NUMA architectures but I do not have enough insight to explore this further. Kind regards robert