Martin Desruisseaux wrote: > I guess that we should put the discussion on a rest for while... The > topic of this post is mostly to insist that your requirements were > understood from the begining (I believe). My feeling is that I failed > to explain why the technical solution - ReadWriteLock - is an > unnecessary overhead for those requirements. The code that I posted > yesterday tries to demonstrate that: it is simplier, use only one lock > (ReentrantLock) instead of two (ReadWriteLock), lets the garbage > collector disposes the lock once the object creation is completed > (instead of keeping the locks indefinitly like ObjectCacheEntry does), > and still should meet all yours requirements. Yes - thank you Martin. It was obvious the moment we looked at the code that you understood the problem. > The hearth of our misunderstanding seems to be here: I claim that if > we remove completly the readLock and still use the ObjectCache in the > same way that you already do (last time I looked in your code), we > will *not* have two workers creating the same CRS in same time because > thread 2 would block anyway when trying to acquire the writeLock (on > key-by-key basis, not for the whole table). When thread 2 finally > acquire the writeLock, the peek() method just after will detect that > the CRS has been created while the thread was blocked. This is the > point that you don't seem to agree on. I agree; we have to move the write lock check into the mediator (instead of just the worker). Once we have done that (and I think the change is already underway) then everything works as you describe. >> The following uses the same line numbers as above (in case you want >> to compare); as we would not see benifit of two locks without more >> threads I have added thread 3 into the mix > > I have read carefully the workflow. We can ommit thread 3 from the > discussion because it queries the cache for a different key (key2), > and consequently uses different locks that do not interfer with thread > 1 and thread 2 locks. I also ommit the internal map synchronization > from this discussion, since it is handled efficiently by > ConcurrentHashMap. We are in agreement since the begining when you > said "We are careful to leave the synchronization of the internal map > block before entering any read/write lock". confirmed - I used Collections.syncrhonizedMap( new HashMap() ) when I ported your code to Java 1.4 - will that do?
>> 45 - thread 2 get() blocks on the readLock > This is the heart of my contestation: If thread 2 didn't blocked here > on readLock (because we remove completly the readLock), thread 2 would > block anyway a little bit later, when it try to acquire the writeLock > while thread 1 already holds it. This is why I claim that the readLock > is useless. Understood; in order to block on the writeLock as in your solution we need to move the writeLock check out into the mediator - which we will now run away and do. Thanks for your patience on this one Martin; talking about concurrency is always tough. Even with the occasional gaps of understand we have done very well here. Until next week (and please enjoy the OGC meeting). Cheers, Jody ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
