[concurrency-interest] Queue quest

Martin Buchholz martinrb at google.com
Mon Apr 14 22:41:56 EDT 2014


CLQ can't get away with the counter because it supports internal removal.
 But it's reasonable for other implementations to do this.

If you read head before tail, you can never have head getting "ahead" of
tail, and then 1 + t.counter - h.counter should be mostly right.


   1.        static long sub(long tail, long head){
   2.                 if (head>tail || ((head^tail)&Long.MIN_VALUE)!=0){




On Mon, Apr 14, 2014 at 2:59 PM, Stanimir Simeonoff <stanimir at riflexo.com>wrote:

>
>
>
>
>> On Mon, Apr 14, 2014 at 4:00 PM, Oleksandr Otenko <
>> oleksandr.otenko at oracle.com> wrote:
>>
>>>  Yes, but capacity availability is tricky to define.
>>>
>>
>> Absolutely, I am open to suggestions!
>>
>>
> Here is an attempt with the described counter:
> http://pastebin.com/fY1AudYY
>
> Basically it is a linked queue w/o CAS on the head due to single consumer
> only, each node has an extra field *long counter *and the current size is
> 1+tail.counter-head.counter.
> poll(long nanos) may return spuriously as it doesn't bother with measuring
> time. Usually that's ok for single consumer queues as they go back to
> poll() if they don't have other tasks to do.
>
>
>
> Stanimir
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140414/b5d9840a/attachment.html>


More information about the Concurrency-interest mailing list