> I guess the try-locks still does not solve the overhead of multiple readers > contending the counter. It just provides a non-blocking version of the same > algorithm.
DPDK project does not use any rwlock for solving any overhead problem of multiple reader (at least I did not find it). For non-critical sections it is often easier to write via rwlock (for to simplify the code). The try locks, relock to read and other are use only for even more simplifies uncritical code. For example some process need change data (write lock), then reread the contents (read lock), it can release write and lock read, but relock to read is easier. Process in the write section can switch to read context and give control for reader function. I sought by third-party solution for rwlock, and decided that rte_rwlock is the best choice for it, especially if there is a relock to read, and try locks. P.S. For solving the overhead problem of multiple readers (if using of locks is _extremely_ required), best practice may be MCS lock and rwlock based on the MCS locks. --- Best regards, Leonid Myravjev On Fri, 13 Jul 2018 at 04:55, Wang, Yipeng1 <yipeng1.w...@intel.com> wrote: > > Thanks for pointing me to this patch. > > I guess the try-locks still does not solve the overhead of multiple readers > contending the counter. It just provides a non-blocking version of the same > algorithm. > > The relock function looks interesting. But it would be helpful if any special > use case or example is given. Specifically, who should call this function, > the reader or the writer? Leonid, could you provide more context? > > The TLRW example I gave is potentially a better rw-lock algorithm. Paper > Reference: D. Dice and N Shavit. "TLRW: return of the read-write lock". In > such scheme, readers won't contend the same reader counter which introduces > heavy cache bouncing that Stephen mentioned. Maybe we should introduce > similar algorithm into rte_rwlock library. > > >-----Original Message----- > >From: Thomas Monjalon [mailto:tho...@monjalon.net] > >Sent: Thursday, July 12, 2018 1:30 PM > >To: Wang, Yipeng1 <yipeng1.w...@intel.com>; Stephen Hemminger > ><step...@networkplumber.org> > >Cc: dev@dpdk.org; De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; > >Richardson, Bruce <bruce.richard...@intel.com>; > >honnappa.nagaraha...@arm.com; vgu...@caviumnetworks.com; > >brijesh.s.si...@gmail.com; Wang, Ren <ren.w...@intel.com>; > >Gobriel, Sameh <sameh.gobr...@intel.com>; Tai, Charlie > ><charlie....@intel.com> > >Subject: Re: [dpdk-dev] [PATCH v5 5/8] hash: add read and write concurrency > >support > > > >12/07/2018 03:22, Wang, Yipeng1: > >> From: Stephen Hemminger [mailto:step...@networkplumber.org] > >> > >> > For small windows, reader-writer locks are slower than a spin lock > >> > because there are more cache bounces. > >> > >> Hi, Stephen, > >> > >> You are correct and we understand that spinlock might be slightly faster > >> than counter based rwlock in this case. However, the > >counter based rwlock is the exception path when TSX fails. > >> > >> If performance of this exception path is a big concern, a more optimal > >> read-write lock scheme (e.g. TLRW) should be introduced into > >rte_rwlock in the future. > > > >Something like this? > > eal/rwlocks: Try read/write and relock write to read locks added > > https://patches.dpdk.org/patch/40254/ > > > > >
