Jody Garnett a écrit :
> Hopefully when we provide some stress tests we will be able to better
> communicate the motivation for using two sets of locks.
Sigh... One of us is really not understanding the other one point. I claim
again
that *the read lock in ObjectCacheEntry is totally useless* i
Thanks Martin - we can use this implementation for testing as well. It
looks like it will be a good solution for the non dispatch case.
Hopefully when we provide some stress tests we will be able to better
communicate the motivation for using two sets of locks.
Jody
> Martin Desruisseaux a écrit
Martin Desruisseaux a écrit :
So there is my proposal: I will commit a ObjectCache2 class (without any
ObjectCacheEntry class) so you can see my point. It will use the modified
workflow that I tried to explain in my previous email.
There is the proposal (not commited because it use Java 5 feat
Cory Horner a écrit :
> With a single write lock for the whole map, we would be constrained to
> create a single object at a time, thus making our worker strategy less
> than effective.
Again I agree and already understood that, but the "only write lock" discussion
was for ObjectCacheEntry, not
Martin Desruisseaux wrote:
> 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...
With a single write lock for the w
Martin Desruisseaux wrote:
> 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 g
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 real
Martin Desruisseaux wrote:
> I understand the sequence of "readLock()", "writeLock()", "get()" and
> "peek()"
> you described. My point is that you don't need the read lock at all for
> achieving exactly what you want to achieve, and consequently ObjectCacheEntry
> don't need to hold a ReadWrit
Jody Garnett a écrit :
> writeLock is a more "serious" locking condition (only one is allowed
> in); by using a read lock we can capture many more threads in the "get"
> method (where many threads are allowed in once reading is available
> again). The effect is on if the map allows concurrent ac
Martin Desruisseaux wrote:
> Yes, but you don't need a "read" lock for that. A single lock (either
> the "write" lock or the plain "synchronized" keyword) is enough.
Perhaps we are talking in circles?
> foo = cache.get(key);
There is a read lock here on the entry; so if a writer is in the proc
[EMAIL PROTECTED] a écrit :
>> 1) Either the "foo" value was already cached (in which case
>> the 'get' method perform a very short locking since it
>> executes nothing more than "return value" - we could even
>> use no lock at all for such a trivial task, since returning
>> a singl
Quoting Martin Desruisseaux <[EMAIL PROTECTED]>:
> ObjectCacheEntry holds a ReadWriteLock. ReadWriteLock are used for example
> with
> HashMap, in order to allows multiple concurrent read operations (on different
> keys) while allowing only one write operation at time.
>
> But with ObjectCacheEnt
ObjectCacheEntry holds a ReadWriteLock. ReadWriteLock are used for example with
HashMap, in order to allows multiple concurrent read operations (on different
keys) while allowing only one write operation at time.
But with ObjectCacheEntry, ReadWriteLock are used on a entry-by-entry level,
which
13 matches
Mail list logo
