[concurrency-interest] Queue quest

√iktor Ҡlang viktor.klang at gmail.com
Tue Apr 15 07:04:26 EDT 2014


Alright, cool, I won't need that.


On Tue, Apr 15, 2014 at 12:07 AM, Stanimir Simeonoff
<stanimir at riflexo.com>wrote:

> Park/Unpark is only for the consumer size if you specify timeout to wait
> for an element. The producer never waits besides the CAS loop.
>
> Stanimir
>
>
> On Tue, Apr 15, 2014 at 1:05 AM, √iktor Ҡlang <viktor.klang at gmail.com>wrote:
>
>> Hi Stanimir,
>>
>> It's really late here, but the presence of park/unpark tells me that this
>> isn't non-blocking.
>>
>>
>> On Mon, Apr 14, 2014 at 11: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
>>>
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>>>>
>
>


-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140415/0b0e7905/attachment.html>


More information about the Concurrency-interest mailing list