[concurrency-interest] LBQ vs CLBQ

Hanson Char hanson.char at gmail.com
Wed Apr 4 18:33:02 EDT 2007


And of course CLBQ cannot be a drop-in replacement for LBQ in the case when
a fixed "capacity" is specified.

Alright, so they are just different implementation of BlockingQueue.

Hanson Char

On 4/4/07, Hanson Char <hanson.char at gmail.com> wrote:
>
> Hi Szabolcs,
>
> >it waits if necessary for space to become available.
>
> In this case it's not necessary and therefore there is no need to wait.
> The condition is still satisfied, isn't it ?  (The statement "if A then B"
> is always trivially true if the condition A is false.)
>
> >This means that on an LBQ the put waits when the queue has already
> >Integer.MAX_VALUE number of elements. It is not the same for your CLBQ
> >if you forward the put to an instance of a ConcurrentLinkedQueue as an
> >add call.
>
> True, they are not the same in the sense that when the number of elements
> in the queue reached Integer.MAX_VALUE.
>
> So I guess technically CLBQ is not a drop-in replacement for LBQ, since
> CLBQ would allow one to continue inserting to the queue and there is always
> no need to wait, whereas LBQ would block if the the number of queue items
> reached Integer.MAX_VALUE.
>
> In practice, however, I doubt if there is any application that would rely
> on this peculiar behavior of LBQ to remain correct.
>
> So CLBQ is not but can be used as a replacement for LBQ in most cases,
> unless your application correctness relies on the queue to block upon the
> number of elements reaching Integer.MAX_VALUE.
>
> Hanson Char
>
> On 4/4/07, Szabolcs Ferenczi <szabolcs.ferenczi at gmail.com> wrote:
> >
> > On 04/04/07, Hanson Char <hanson.char at gmail.com > wrote:
> > > The put method in CLBQ, being unbounded, will always succeed
> > "immediately"
> > > without waiting.  But waiting with zero time doesn't mean it does not
> > > satisfy the contract of the BlockingQueue put method, as the
> > happen-before
> > > relationship is still satisfied by the current implementation.
> > >
> > > Or am I missing something here ?
> >
> > Hi Hanson,
> >
> > I think you miss that the semantics of put in the interface
> > BlockingQueue says that it waits if necessary for space to become
> > available. It is not the same as method add which does not wait but
> > returns a boolean.
> >
> > On the other hand, you claim that your CLBQ can replace LBQ. Now LBQ
> > is bounded. By default, the capacity is Integer.MAX_VALUE . This means
> > that on an LBQ the put waits when the queue has already
> > Integer.MAX_VALUE number of elements. It is not the same for your CLBQ
> > if you forward the put to an instance of a ConcurrentLinkedQueue as an
> > add call. Do you agree?
> >
> > Best Regards,
> > Szabolcs
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070404/68f1347a/attachment.html 


More information about the Concurrency-interest mailing list