[concurrency-interest] Changing delays in DelayQueue ?
tim at peierls.net
Thu Sep 7 20:03:00 EDT 2006
I was assuming the change of delay was a rare occurrence.
As I said, too bad we don't have decreaseKey.
If you are free to use Mustang, consider rolling your own with
On 9/7/06, Hanson Char <hanson.char at gmail.com> wrote:
> Wouldn't the DelayQueue.remove(Object) take O(n) time ? And wouldn't that
> lock the entire queue in the meantime ? If so, the concurrency is
> significantly compromised!
> On 9/7/06, Tim Peierls <tim at peierls.net> wrote:
> > You can remove a and b, change their delays, and then put them back into
> > the delay queue.
> > Too bad we couldn't find a nice way for PriorityQueue (and PBQ) to
> > support a decreaseKey operation.
> > --tim
> > On 9/7/06, Hanson Char <hanson.char at gmail.com> wrote:
> > > Javadoc of j.u.c.DelayQueue:
> > "The *head* of the queue is that Delayed element whose delay expired
> > furthest in the past."
> > I've been wondering, after the elements have been enqueued, if the above
> > "invariant" could still be maintained even if the delays of the elements are
> > modified (such that the order of the delays become different from those as
> > at the time when the elements were inserted.)
> > Example,
> > 1) enqueue elements [a, b], whereas a.delay < b.delay
> > 2) modify a and b such that b.delay < a.delay
> > 3) dequeue elements
> > It would be nice if (3) could result in the order of [b,a], instead of
> > [a,b], which is the existing behavior of DelayQueue.
> > Is there an easy way to achieve the desired behavior without
> > compromising concurrency ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest