Re: PriorityBlockingQueue question

I had time for a quick scan only right now. I noticed a lock.lock()/unlock() pair that doesn't match the "approved" pattern: in getQueueForMessageSelector. Since you aren't using lockInterruptibly or any of the other features of RL, why not just use synchronized? 

--tim

On 10/4/06, David Walend <david@xxxxxxxxxx> wrote:

On Sep 26, 2006, at 11:11 AM, Tim Peierls wrote:

> On 9/26/06, Tim Peierls <tim@xxxxxxxxxxx> wrote:
> No ideas for this -- I'm thinking about the other approach.
>
> What if you maintained a separate queue for each selector and
> atomically marked messages when consumed? (You could use
> AtomicMarkableReference.attemptMark, for example.) Then you don't
> have the problem of having to remove a message from all other
> queues, since receivers can simply ignore messages that someone
> else marked.

Thanks for the suggestion, Tim.

See https://somnifugijms.dev.java.net/source/browse/somnifugijms/v3/
source/somnifugi/net/walend/somnifugi/juc/
MessageSelectingPriorityBlockingQueue.java?rev=1.3&view=auto&content-
type=text/vnd.viewcvs-markup for a new version.

I like this one a lot. JMS QueueSenders handle the message selector
workings inside offer(). JMS QueueReceivers with no message selector
(and will use the ALLMESSAGESELECTOR) will have something close to
PBQ performance. QueueReceivers with messages selectors will still
have to do a PBQ scan in the remove() method, but that's the only
disappointing thing. Everything else should be very live.

Thanks again for the help. Please let me know if you see any problems
when you flip through the code.

Dave

David Walend
david@xxxxxxxxxx

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@xxxxxxxxxxxxxxxxxxxx
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest