Cory Horner a écrit :
> We are focusing on both concurrency *and* avoiding duplication of work
> in the construction of the Referencing objects. The get() method should
> block precisely because a write lock has been obtained and someone is in
> the process of generating its value.
Yes, I really understand that, but you don't need a read lock at
ObjectCacheEntry for that!
> Our designed workflow is as follows:
editing the workflow...
> - thread 1 get() returns null from cache miss
> - thread 1 acquires a write lock
> - thread 1 starts building the referencing object
*** MODIFICATION BEGIN
> - thread 2 get() returns null from cache miss
> - Thread 2 try to acquire a write lock
> - Thread 2 block because thread 1 already has the write lock
*** MODIFICATION END
> - thread 1 finishes building the referencing object
> - thread 1 stores the value in the cache
> - thread 1 releases the write lock
*** MODIFICATION BEGIN
> - thread 2 acquires the write lock
> - thread 2 realize that the object is already created (because of the call
> to
peek()), so it doesn't create it again.
> - thread 2 obtains the referencing object from the cache
> - Thread 2 releases the write lock
**** MODIFICATION END
> As you can see, we need a more complex design to support this -- do you
> agree with our justification?
Not really... I don't see the need for a read lock in an Entry, unless my
modified workflow above if flawed. In my understanding, the ReadWriteLock is
designed for objects like HashMap in a whole, note individual Map.Entry...
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
