[concurrency-interest] PriorityQueue bug with mutable object

karnok at sztaki.hu karnok at sztaki.hu
Sat Jul 4 05:00:27 EDT 2009


I think, the resubmission of the prioritized task is a solution to the  
problem, for now. You need to combine the reliable messaging concept  
with the priority queue (and immutability).
Have your object include an 'unique' task id. Keep a reference to the  
task in a separate thread, which should compute the new priorities  
periodically, and resubmit the task *with the same UID* to the  
priority queue. If the original task is already at the head, then the  
poller will get it now and perform the operation. The poller will then  
discard any further same UIDs and let the re-prioritizer thread also  
ignore this task further on.

Quoting Doug Lea <dl at cs.oswego.edu>:

>> I understand this and in fact I was expecting that kind of response from
>> Sun. However since they accepted the bug I was lead to believe that it
>> might actually be a bug.
> As Martin mentioned, this doesn't mean much.
> And as others mentioned, this is Not A Bug. But it is
> implicitly an RFE. We don't provide a class that permits
> re-weightings. Part of the reason is algorithmic. In
> all the usual priority queue algorithms, you can't
> re-weight unless you can locate, which you don't want
> to have to do via sequential search. The usual way out
> of this is to embed inverse indices etc inside user
> elements, which we also cannot do. However, it would be
> possible to create separate indexing structure (maybe
> a hash table of some sort) for those usages that can
> tolerate extra time/space overhead for sake of extra
> functionality. This might be worth exploring someday.
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

This message was sent using IMP, the Internet Messaging Program.

More information about the Concurrency-interest mailing list