| |||||||||||||
Reader-to-updater upgrade?Reader-to-updater upgrade?Posted Jan 10, 2008 13:58 UTC (Thu) by jarkao2 (guest, #41960)In reply to: Reader-to-updater upgrade? by PaulMcKenney Parent article: What is RCU? Part 2: Usage
1. "However, a separate synchronization mechanism must be supplied to keep the writers from destructively interfering with each other, as noted in the first list above." Maybe I miss or repeat something, but serious downsize of this upgrade-to-write seems to be in this possibly stale value of the search got as an RCU reader, which would always(?) require additional verification. 2. This example: "RCU is a Restricted Reference-Counting Mechanism [...] Regardless of these restrictions, the following code can safely delete p: 1 spin_lock(&mylock); 2 p = head; 3 head = NULL; 4 spin_unlock(&mylock); 5 synchronize_rcu(); /* Wait for all references to be released. */ 6 kfree(p); [...]" should probably promote rcu_assign_pointer() more... 3. "And" maybe one more tiny fix: "RCU is a Bulk Reference-Counting Mechanism [...] starting and I/O and released [...]" Many thanks!
(Log in to post comments)
Reader-to-updater upgrade? Posted Jan 10, 2008 21:02 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link] 1. Indeed, the upgrade-to-update change would be visible to the remainder of the RCU read-side critical section. However, in a surprisingly large number of cases, there is no need for additional verification steps (though verification can be used when needed). This is a key difference between RCU and non-blocking synchronization (NBS) -- NBS would absolutely require the validation steps in order to avoid memory corruption. 2. Good point -- although rcu_assign_pointer(head, NULL) is superfluous, it is good practice, and there is no performance penalty. 3. Good eyes!!!
|
|||||||||||||