[dpdk-dev] [PATCH v3 1/3] ring: read tail using atomic load

Ola Liljedahl Ola.Liljedahl at arm.com
Mon Oct 8 17:45:28 CEST 2018



On 08/10/2018, 16:46, "Ola Liljedahl" <Ola.Liljedahl at arm.com> wrote:

    
    
    On 08/10/2018, 16:44, "Bruce Richardson" <bruce.richardson at 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
        
    
    



More information about the dev mailing list