[concurrency-interest] PriorityBlockingQueue question

Tim Peierls tim at peierls.net
Wed Oct 4 10:06:53 EDT 2006

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?


On 10/4/06, David Walend <david at walend.net> wrote:
> On Sep 26, 2006, at 11:11 AM, Tim Peierls wrote:
> > On 9/26/06, Tim Peierls <tim at peierls.net> 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 at walend.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061004/6bef9781/attachment.html 

More information about the Concurrency-interest mailing list