[concurrency-interest] Queue quest

Stanimir Simeonoff stanimir at riflexo.com
Tue Apr 15 18:52:33 EDT 2014


Thank you!
It makes sense.

Stanimir


On Wed, Apr 16, 2014 at 12:30 AM, Martin Buchholz <martinrb at google.com>wrote:

>
>
>
> On Mon, Apr 14, 2014 at 11:46 PM, Stanimir Simeonoff <stanimir at riflexo.com
> > wrote:
>
>>
>>
>>
>> On Tue, Apr 15, 2014 at 5:41 AM, Martin Buchholz <martinrb at google.com>wrote:
>>
>>> 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){
>>>
>>>
>>>
>>> It's mostly meant as gimmick to support unsigned counter, i.e.
>> overflowing  long and having negative counter.
>>
>
> I believe my simple recipe supports even in the (unlikely) case that the
> long counter overflows, as with the counter you get back from
> System.nanoTime()
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140416/263b00a7/attachment.html>


More information about the Concurrency-interest mailing list