Is writer starvation a potential problem with RCU?
Jeff.Haran at citrix.com
Mon Feb 9 12:24:07 EST 2015
> -----Original Message-----
> From: michi1 at michaelblizek.twilightparadox.com [mailto:michi1 at michaelblizek.twilightparadox.com]
> Sent: Saturday, February 07, 2015 1:29 AM
> To: Jeff Haran
> Cc: kernelnewbies at kernelnewbies.org
> Subject: Re: Is writer starvation a potential problem with RCU?
> On 18:19 Fri 06 Feb , Jeff Haran wrote:
> > I've read that the Linux implementation of read-write locks (rwlock_t) can suffer from so called "writer starvation", whereby threads
> that take a read lock on a read-write lock can prevent threads attempting to take a write lock on the same read-write lock from ever
> acquiring the lock because there is no queuing of the readers and writers. If the lock is held for read access, any subsequent reader
> will get the lock even if a write lock attempt is already in progress.
> > Does anybody happen to know whether or not RCU has a similar issue?
> Why should it have this issue?
> An RCU read is basically an atomic pointer read. One writer and multiple
> readers can run concurrently. When the writer is finished, it updates the
> atomic pointer.
> The issue you may need to worry about is freeing the memory of the old
> pointer. This can only be done after all readers have finished (see
> synchronize_rcu() and call_rcu()). Depending on what you do, you may see high
> memory usage or writers which are blocked waiting for readers to finish.
More information about the Kernelnewbies