Re: where's your Vector, victor
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