[lttng-dev] question about the RCU variant in CITRUS tree paper
Paul E. McKenney
paulmck at linux.vnet.ibm.com
Thu May 11 20:23:03 UTC 2017
On Thu, May 11, 2017 at 04:05:45PM -0400, Yuxin Ren wrote:
> Hi,
>
> I am learning U-RCU now.
> And I read paper Concurrent Updates with RCU: Search Tree as an Example
> ( https://pdfs.semanticscholar.org/73e4/cd29273cf9d98d35bc184330e694ba798987.pdf
> )
>
> In this paper, the authors present a variant RCU implementation, and
> argued their new RCU has better performance than default U-RCU.
>
> Do you think their argument and implementation is correct in all cases?
> If they are right, will you wan to integrate their improment to U-RCU
> implementation?
>
> For your convenience, I paste the related text from the paper here.
> "In our implementation, each thread has a counter and flag, the
> counter counts the number of critical sections executed by the thread
> and a flag indicates if the thread is currently inside its read-side
> critical section. The rcu_read_lock operation increments the counter
> and sets the flag to true, while the rcu_read_unlock operation sets
> the flag to false. When a thread executes a synchronize_rcu operation,
> it waits for every other thread, until one of two things occurs:
> either the thread has increased its counter or the thread’s flag is
> set to false. "
>
> One its implementation can be found from synchrobench
> https://github.com/gramoli/synchrobench/blob/master/c-cpp/src/trees/tree-lock/new_urcu.c
I covered this one here: https://lwn.net/Articles/667593/
The short version is that they are working around what I consider to
be a design bug in their algorithm, namely that they are holding the
update-side lock across RCU grace periods. They do this to achieve
linearizability, which is prized by many conference referees/reviewers,
but not as useful in practice as is commonly supposed.
But it does have a broken URL to the paper, so I will send your working
version to the LWN editors CCing you. Thank you for that!
Thanx, Paul
More information about the lttng-dev
mailing list