HashSet is not concurrent. Would it be better to just use ConcurrentHashMap to eliminate the use of synchronize?
Gregg Wonderly Sent from my iPhone On Jul 17, 2010, at 9:49 PM, Peter Firmstone <[email protected]> wrote: > Sounds like a good optimisation, I'm for it. I agree, don't but all the > tasks in the HashSet, just those you don't want duplicated. > > Patricia Shanahan wrote: >> TaskManager has a method addIfNew(Task t) that adds a Task if, and only if, >> there is no existing task that it equals, according to .equals comparison. >> >> It has one existing use, adding an AddressTask in >> com.sun.jini.reggie.RegistrarImpl. All instances of AddressTask are added >> using addIfNew. AddressTask is final, and an AddressTask considers itself >> equal only to other instances of AddressTask. >> >> I would like to modify TaskManager so that addIfNew adds the new Task unless >> there is an equal Task that was also added using addIfNew. The new javadoc >> comment would read: >> >> /** >> * Add a new task if it is not equal (using the equals method) >> * to any existing active or pending task that was also added >> * by this method. >> */ >> >> This permits a very simple implementation that does not depend on an O(n) >> scan of all existing tasks. addIfNew would add the Task to a HashSet<Task>, >> and do the rest of the processing if, and only if, the HashSet add method >> returns true. I would remember if a particular Task came through addIfNew, >> and if it did it will be removed from the HashSet on completion or removal. >> >> This implementation would fully meet the needs of the existing use, at least >> once I improve the hashCode method in AddressTask. >> >> The problem with putting all added Task instances in the HashSet is that the >> add method permits addition of multiple tasks that equal each other. I could >> work around that problem, but it would make the code significantly more >> complicated, and add work to the normal case of unconditionally added tasks. >> >> Patricia >> >
