directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: svn commit: r1057707 - /directory/apacheds/branches/apacheds-AP/core-api/src/main/java/org/apache/directory/server/core/administrative/SubentryCache.java
Date Tue, 11 Jan 2011 16:33:59 GMT
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


Mime
View raw message