3 ms·

sbahra is correct; at the very least, in release 6, the order of pointer and counter reading is incorrect. This was fixed a long time ago, but release 7 hasn't

sbahra is correct; at the very least, in release 6, the order of pointer and counter reading is incorrect. This was fixed a long time ago, but release 7 hasn't yet come out; I've added an entry to the known issues page in the wiki. The counter needs to be read first and not doing so permits ABA. The queue is MPMC and as such is much heavier than the memory-barrier-only SPSC circular buffer.

liblfds_admin 14y ago
I should quantify this. The pointer/counter bug was fixed a long, long time ago, but at the time slipped through the net with regard to being published on the known issues page. That was a very unfortunate oversight. Sbahra emailed a few weeks ago to inform me of the issue (and the others he raises) and I checked the existing code base, to see the pointer/counter issue already fixed and the other issues unclear (specifics were not given). I replied, but no reply - but sbahra is a busy guy and also very competent, so I consider it likely his comments have merit; I will look further into them once I've finished my immediate release 7 work. With regard to adding the pointer/counter issue to the known issues page, this I did today - I thought about it earlier, but release 7 was is so close to coming out and the bug has been present for so long, it seemed a pretty moot point (actually of course that's completely untrue; people using six need to know, so they can know to update their code).
liblfds_admin 14y ago
I've spent an hour or two looking more closely at the pointer/counter ordering behaviour in the queue. I'm going to go out a bit on a limb (this is mental code inspection only) and say it's not in fact a problem. It IS a problem in a stack which increments the counter only on push, but it's NOT a problem in the M&S queue because of the checking logic which follows the pointer/counter read. If there has been a torn read, where the pointer and counter don't match, then the main loop will simply iterate and retry, because the counter doesn't match; and it's being incremented on queue and dequeue.

liblfds_admin 14y ago

I should quantify this. The pointer/counter bug was fixed a long, long time ago, but at the time slipped through the net with regard to being published on the known issues page. That was a very unfortunate oversight. Sbahra emailed a few weeks ago to inform me of the issue (and the others he raises) and I checked the existing code base, to see the pointer/counter issue already fixed and the other issues unclear (specifics were not given). I replied, but no reply - but sbahra is a busy guy and also very competent, so I consider it likely his comments have merit; I will look further into them once I've finished my immediate release 7 work. With regard to adding the pointer/counter issue to the known issues page, this I did today - I thought about it earlier, but release 7 was is so close to coming out and the bug has been present for so long, it seemed a pretty moot point (actually of course that's completely untrue; people using six need to know, so they can know to update their code).

liblfds_admin 14y ago

I've spent an hour or two looking more closely at the pointer/counter ordering behaviour in the queue. I'm going to go out a bit on a limb (this is mental code inspection only) and say it's not in fact a problem. It IS a problem in a stack which increments the counter only on push, but it's NOT a problem in the M&S queue because of the checking logic which follows the pointer/counter read. If there has been a torn read, where the pointer and counter don't match, then the main loop will simply iterate and retry, because the counter doesn't match; and it's being incremented on queue and dequeue.