0

My question is actually specific to the rcu list implementation of linux. I need to hold a spinlock for any critical sections which is reading from the list and updating (say deleting that entry), because the rcu version it sees after the read might not be fit for an update. So for my case, I have most threads doing updates in some point or the other. Do you think there is a way to efficiently utilize (i.e. minimizing the section for which the spinlock is held) the rcu implementation in such scenarios?

Akhil
  • 1,073
  • 1
  • 9
  • 28
Sharvanath
  • 457
  • 4
  • 15

1 Answers1

0

RCU is good when there are very few updates, compared to reads.

I don't see how it's relevant that all threads are potential updaters. If they actually update frequently, RCU isn't for you. If they update rarely, it may be good.

ugoren
  • 16,023
  • 3
  • 35
  • 65
  • No that point is, if you have only one updater you can just use RCU. But if there are multiple of them, you probably need a lock. So RCU is useful if there are not multiple updaters. Do you buy my argument? – Sharvanath Aug 09 '13 at 05:13
  • I don't see why the number of updaters matters. Only their frequency. RCU allows readers to suffer almost no overhead as long as there are no updates currently, which is very useful regardless of the number of writers. – ugoren Aug 09 '13 at 05:15
  • if you have multiple updaters, each has to use a write lock, this would affect the performance. I guess the point of rcu is not just for no updates, even if you have concurrent updates I think it is better than a futex (which has no overhead unless there is contention). The idea of RCU is to have multiple views of the data-structures. However, if you have multiple updaters this algorithm doesn't ensure any synchronization among the updaters. Does that make sense? – Sharvanath Aug 09 '13 at 05:21