Parking value not exclude // Wrap around not handled about blog HOT 3 CLOSED

Hi!

I use unsigned long, which is 64 bits in size, exactly to avoid overflow issues as well as additional cost on integer overflow management. If we suppose a 3Ghz processor incrementing unsigned long variable each tick, then it'll require almost 195 years to overflow the variable

    $ perl -le 'print +(~0 / 3_000_000_000 / 3600 / 24 / 365)'
    194.980805785024

So we can safely suppose that we're safe from integer overflows.

from blog.

for x64, you're certainly correct. for x86 32, long is 32 bits, at least on compilers with which I'm familiar, and people still build and run 32 bit code, At the rate of about 100ns per push or pop operation I measured for boost::lockfree in my testing, would overflow in about 20 minutes.

Probably the simplest fix is to detect 32bit at compile time and typedef the counters to ulonglong... or just use uint64_t to begin with :) -- though it would be interesting to bench the overflow management logic versus the additional width.

BTW -- brilliant article, clearest exposition on a lock-free design I've read

from blog.

The queue is designed specially for x86_64 and we ever check this at compile time https://github.com/krizhanovsky/NatSys-Lab/blob/master/lockfree_rb_q.cc#L25 .

And thanks for good words ;)

from blog.