On 08/10/2018, 16:46, "Ola Liljedahl" <ola.liljed...@arm.com> wrote:
On 08/10/2018, 16:44, "Bruce Richardson" <bruce.richard...@intel.com> wrote:
On Mon, Oct 08, 2018 at 09:22:05AM +0000, Ola Liljedahl wrote:
<snip>
> "* multi-producer safe lock-free ring buffer enqueue"
> The comment is also wrong. This design is not lock-free, how could it
be when there is spinning
> (waiting) for other threads in the code? If a thread must wait for
other threads, then by definition
> the design is blocking.
>
My understanding is that the code is lock-free but not wait-free, though
I'm not an expert in this area.
Notice this code:
while (br->br_cons_tail != cons_head)
cpu_spinwait();
Waiting for another thread to update a specific location => blocking.
Sure, the code doesn't use locks but that doesn't make it lock-free (in the
computer science meaning).
Well to be more specific. The BSD and DPDK ring buffer is lock-free between
consumer-side and producer-side
(regardless whether SP/SC or MP/MC). But it is blocking between multiple
producers and between multiple consumers.
The waiting for tail here is similar to a ticket lock. You take a ticket using
CAS (because the ticket space
isn't infinite), you can overlap processing (because all threads read or write
different slots in the ring),
but then you must release your ticket in the order in which it was taken. So
you wait for any earlier thread(s).
Waiting is blocking. If any earlier thread doesn't release its updates, you get
stuck.
/Bruce
