[vlc-devel] [PATCH 2/3] threads: rewrite R/W lock to avoid contention

[Rémi Denis-Courmont]

Le keskiviikkona 13. tammikuuta 2021, 9.28.23 EET Steve Lhomme a écrit :
> On 2021-01-12 18:30, remi at remlab.net wrote:
> > From: Rémi Denis-Courmont <remi at remlab.net>
> > 
> > The current implementation would cause threads to sleep upon concurrent
> > read lock/unlock. This fixes that. Sleeping now only occurs when writers
> > are involved.
> 
> I suppose the goal is to make reading lock-free. But there's a slight
> difference in the unlock part.
> 
> * Before: Let reader and writer compete. OS scheduler decides who wins.
> * After: Wake waiting readers, then Wake one waiting writer

On reader unlock, readers are advantaged because they will not wait (even if 
there is a pending writer). This does not change.

On writer unlock, strictly speaking the scheduler decide who wins. This does 
not change either. There may be a slight bonus for readers.

> So now the reader always get priority over the writer ? Is it possible
> that a fast reader (and lock-free) will never let the writer be in charge ?

Yes. This was already a theoretical problem with the previous code. In 
particular, readers could form a chain where there is always at least one 
reader, and writers never get the lock. This is necessary for recursive reader 
locking to work.

In practice, it's up to the use case to ensure that reader critical section 
are fast enough that this does not happen. We could fix this using RCU locks 
instead of RW locks, but it's a lot more involved on the side of the use 
cases.

> Also you don't need to forward declare vlc_rwlock_tryrdlock, just move
> the definition.

I know but I stick to the defactor function ordering convention of the rest of 
the same file.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/