Is writer starvation a potential problem with RCU?

Is writer starvation a potential problem with RCU?

[Jeff Haran]

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?

Thanks,

Jeff Haran

Is writer starvation a potential problem with RCU?

[michi1 at michaelblizek.twilightparadox.com]

Hi!

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.

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com

Is writer starvation a potential problem with RCU?

[Jeff Haran]

> -----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?
> 
> Hi!
> 
> 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.
> 
> 	-Michi

Thanks,

Jeff Haran