Re: [dpdk-dev] [PATCH v2] eal/rwlock: add note about writer starvation

[Thomas Monjalon <thomas@monjalon.net>]

Ping again. Stephen?


12/05/2021 21:10, Thomas Monjalon:
> Ping for v3
> 
> 12/02/2021 01:21, Honnappa Nagarahalli:
> > <snip>
> > 
> > > 
> > > 14/01/2021 17:55, Stephen Hemminger:
> > > > The implementation of reader/writer locks in DPDK (from first release)
> > > > is simple and fast. But it can lead to writer starvation issues.
> > > >
> > > > It is not easy to fix this without changing ABI and potentially
> > > > breaking customer applications that are expect the unfair behavior.
> > > 
> > > typo: "are expect"
> > > 
> > > > The wikipedia page on reader-writer problem has a similar example
> > > > which summarizes the problem pretty well.
> > > 
> > > Maybe add the URL in the commit message?
> > > 
> > > >
> > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > ---
> > > > --- a/lib/librte_eal/include/generic/rte_rwlock.h
> > > > +++ b/lib/librte_eal/include/generic/rte_rwlock.h
> > > > + * Note: This version of reader/writer locks is not fair because
> >                                 ^^^^^^ may be "implementation" would be better?
> > 
> > > > + * readers do not block for pending writers. A stream of readers can
> > > > + * subsequently lock out all potential writers and starve them.
> > > > + * This is because after the first reader locks the resource,
> > > > + * no writer can lock it. The writer will only be able to get the
> > > > + lock
> > > > + * when it will only be released by the last reader.
> > This looks good. Though the writer starvation is prominent, the reader starvation is possible if there is a stream of writers when a writer holds the lock. Should we call this out too?
> > 
> > > 
> > > You did not get review, probably because nobody was Cc'ed.
> > > +Cc Honnappa, Joyce and Konstantin