[concurrency-interest] Changing delays in DelayQueue ?

Tim Peierls 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
ConcurrentSkipListMap.

--tim

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!
>
> Hanson
>
>
> 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...
URL: /pipermail/attachments/20060907/17e9d51d/attachment.html 


More information about the Concurrency-interest mailing list