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.
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.
The remainding of this post just repeat the above summary as comments inlined
with your post, in order to put them in some context.
Jody Garnett a écrit :
> The problem we
> are trying to solve is not only cache consistency, but allowing multiple
> workers to be in flight at the same time. This is required so we can
> have each working on creating different referencing objects,
> *concurrently*.
Yes, I understood that from the very begining...
> If we just had a single lock on the map we would only be able to work on
> a creating a single referencing object at a time. By having a second
> lock on the "map entry" we are able to have several workers going at
> once - each working on a defining a different value.
...and this is what I'm contesting from the begining (the technical, not the
goal).
> 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".
> (...snip...)
> 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.
Jesse Eicher a écrit :
> Problem that I see with Martin's solution:
>
> Multiple referencing object cannot be created concurrently because line 20
> acquires the lock on the table.
No, line 20 acquires to lock for the key. I claim that a single ReentrantLock
is
suffisient for that, not a ReadWriteLock.
> Martin: If you can convince me that your code can satisfy that requirement
> then
> you've won me :) .
>
> Rephrasing requirement:
> CRS1 and CRS2 can be created concurrently. CRS1 will only be created once.
Again I understood this requirement from the begining, and I think that my code
satisfy it from the very begining too. Just keep in mind that line 20 acquires
the lock for the key, not for the table.
Jody Garnett a écrit :
> First the good news - we are both putting forward the same solution
> (in terms of the important two locks in place when writing).
I use only one lock (ReentrantLock) instead of two (ReadWriteLock). In addition
the locks are completly discarted once the creation is completed, instead of
keeping them indefinitly in ObjectCacheEntry.
Regards,
Martin
-------------------------------------------------------------------------
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
