and this is not the case. In the "cache" example the reads are very short (just returning an object from a Map, mostly) so the contention between reading threads would be less than the overhead that ReadWriteLock introduces to check whether it needs to lock the access or not. Not saying that the library is not useful, but just that in this specific case I think we might loose more than what we win.
...The methods are relatively time-consuming (as a rough rule of thumb, exceed more than a hundred instructions), so it pays to introduce a bit more overhead associated with ReadWrite locks compared to simple synchronized methods etc in order to allow concurrency among reader threads.
GreenEyed wrote:Well, [....] My 2ec