<snip> > > > >> > >> The current version of rte_rwlock doesn't do what it says in the > >> documentation. > >> " The lock is used to protect data that allows multiple readers in > >> parallel, but only one writer. All readers are blocked until the writer is > finished writing." > >> > >> The problem is that the current implementation does not stop a a new > >> reader from acquiring the lock while a writer is waiting. > > Agree, essentially the arbitration is left to the hardware. > > > >> > >> Writer: > >> repeat until x = __atomic_load(&counter) == 0; > >> __atomic_compare_exchange(&counter, &x, -1); > >> > >> Reader: > >> x = __atomic_load(&counter); > >> __atomic_compare_exchange(&counter, &x, x + 1); > >> > >> > >> Fixing it likely would require an ABI change to add additional state. > >> > >> For more background on reader-writer locks see: > >> > >> https://www.cs.rochester.edu/research/synchronization/pseudocode/rw.h > >> tm > >> l > >> > >> The code in DPDK is actually effectively the same as the first > >> example "Simple, non-scalable reader-preference lock" > > I do not think the DPDK implementation has reader-preference. There is no > code to control the arbitration between writers and readers. It is possible > that if > there are multiple writers the readers might be starved depending on how the > hardware does the arbitration. > > > > As far as I can see, in current implementation: > > When writer has the lock, both writers and readers needs to wait, and when > writer releases reader or writer has chance to acquire the lock. Yes, since reader or writer can acquire the lock (when writer releases), I do not think we can call the current implementation as 'reader-preference'.
> > When reader has the lock, other readers can acquire the lock and writers has > to > wait, and if readers keep coming it can cause writer starvation. Overall this > doesn't look fair reader-writer lock ... Agree > > >> > >> It looks like doing the right thing will require increasing the size > >> of the rte_rwlock structure and cause an ABI breakage. > >> > >> I am running with an alternative which uses ticket locks to do: > >> "Simple, non-scalable writer-preference lock" > > Does it provide good scalability? > > > >> > >> My recommendation would be: > >> > >> 1. Fix documentation in rte_rwlock.h (and add release note) and put > >> this in > >> 20.02 and LTS. > > Agree, the document is not clear on the arbitration. > > > >> 2. Add new rte_ticket_rwlock.h which provides the correct semantics. > > Agree. > > > >> > >> Comments?
