On 1/11/11 5:13 PM, Felix Knecht wrote:
I don't see the need of locking in methods like "public boolean
hasSubentry(...)". What's the benefit of locking?
To protect the reader from getting through a path which is modified just
in the middle by a write. Of course, in this very case, if uuidCache
were a synchronized class, which is not the case, we would be safe. But
you have to remember that an hashMap is an array under the hood, and you
may perfectly be caught in a situation where you try to access an array
being duplicated at the very same time by a write. The result would be
random.
A normal use case is IMO that some time after calling the has...
method one will either read or write the cache.
But there's no garantee, that when now read/write the cache is still in
the same state as when calling the has... method. So isn't it just a
waste of time to lock in this case?
no, the real problem is if a write occurs *exacly* in the middle of a
hasXXX() processing. yes, very unlikely, but when you have hundred of
threads, it *may* occur. And we don't want to deal with such painful
situations.
So, bottom line, it's not about the result you get back from the
operation itself, but the potential NPE, or whatever ArrayOOB you may
obtain.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
