| |||||||||||||
Race condition?Race condition?Posted Jul 18, 2002 16:47 UTC (Thu) by bjn (guest, #2179)Parent article: Read-copy-update Thanks for the write-up on RCU; a good summary, as usual. However, you don't say anything about how RCU prevents two writers from trying to work at once (race condition)?
(Log in to post comments)
Race condition? Posted Jul 18, 2002 17:04 UTC (Thu) by corbet (editor, #1) [Link] In fact, there really isn't anything in the RCU patch to prevent multiple writers from working concurrently. Whoever updates the data pointer last wins. For the sorts of uses envisioned by the RCU authors (i.e. routing tables, loadable modules, etc.), this usually isn't a problem. There will not normally be concurrent writers, and especially not situations where one would depend on what the other is writing.One certainly see situations where a write-side race condition would be a problem, though. The solution would be to put a spinlock around the copy-update part of the cycle.
Race condition? Posted Jun 13, 2003 17:40 UTC (Fri) by ncm (subscriber, #165) [Link] In other words, the (overwhelmingly) most frequent users of the data structure never need to lock it. Concurrent writers do need to lock, but since writing happens so rarely, collisions requiring one writer to wait are vanishingly rare. Where you can guarantee there can be no writer collisions (e.g. there's only ever one writer, or they're already co-operating), writers don't need to lock.The more subtle danger is when there is a dependency relationship between the data copied, and other data elsewhere in the kernel (or in user space!). You just have to be very careful never to let that happen.
|
|||||||||||||