Optimized Syncronized list?
Recently i noticed that Collections.synchronizedList(List) implementation was based on a "simple" synchronize block wrapping delegated calls to original List.
This suprised me as i was expecting something better than Vector implementation. (which is also based on synchronized blocks).
In my opinion, this implementation is not the best as it doesn't allow simultaneous calls to "read" methods.
I wrote a synchronizedlist wrapper allowing simultaneaous read calls.
My impl has better performances (about a factor 3-4) while doing as many read/write operations.
So, here is my question.
Why is the current implementation this way, and do you know if it is going to change ?
[716 byte] By [
ibanna] at [2007-11-27 7:48:55]

# 1
because it is a cheap, simple solution to synchronization that works for all list implementations (not necessarily fast but generally not a performance issue). If you want a more concurrent list then you really need to know your usage patterns. JDK 1.5 provides the concurrency package. It contains a CopyOnWriteArrayList. This allows multiple readers to read concurrently from it but requires the underlying array be copied on a write. This is great if you mostly read stuff but can really impact performance if you write alot.
If you are performing list.get(int i) operations on your synchroniszed list then you beter hope that the underlying list is NOT a LinkedList (other threads will be blocked while you search the list for the element)
matfud