User: Password:
|
|
Subscribe / Log in / New account

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!!!


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds