An interesting possibility. Having learned about Java concurrency in the
bad old days of explicit wait and notify, I'm still in the process of
wrapping my mind around the java.util.concurrent features.
My latest TaskManager implementation uses explicit threads and a
BlockingPriorityQueue to do the dispatch. I may change that later to use
something more automatic.
I use a TaskWrapper (IdentityHashMap<Task,TaskWrapper> to connect it to
the caller-implemented Task) so that I can make changes like that
without affecting TaskManager callers at all. It might affect the
interfaces a TaskWrapper implements, or the fields it has, but it would
not affect TaskManager.Task.
Patricia
On 7/19/2010 5:13 PM, Gregg Wonderly wrote:
Also think about simple Future characteristics and use. Being about to
use CHM.putIfAbsent() with a Future value, allows an "early" elimination
of duplicate tracking so that early on, the Future can represent the
final value, but also have queryable state to see where it is at in
getting through these 3 steps.
Gregg Wonderly
Patricia Shanahan wrote:
Possibly. It is certainly a good method to keep in mind, so thanks for
the reminder.
RegisterImpl can have three relationships to the data its AddressTask
collects for a given host and port:
Knows nothing.
Is getting it.
Has it.
I'll have to look at RegisterImpl in general, and its synchronization
design in particular, to see how all this is represented, and how the
duplication issue can be handled most smoothly.
Patricia
Gregg Wonderly wrote:
Would not ConcurrentHashMap.putIfAbsent() help with some of the
duplicate checking?
