From: Mathieu Desnoyers Date: Sun, 14 Mar 2010 19:33:51 +0000 (-0400) Subject: urcu: Add extra "engineering safety factor" memory barrier in update_counter_and_wait() X-Git-Tag: v0.4.4~7 X-Git-Url: https://git.lttng.org./?a=commitdiff_plain;h=935b11ff4cf9053954d21b9d63c4ee367b12a652;p=urcu.git urcu: Add extra "engineering safety factor" memory barrier in update_counter_and_wait() Even though the memory barriers within update_counter_and_wait() are proven not to be needed in urcu-mb/signal/qsbr implementations, we leave them in place as an engineering safety factor. Basically, we've proven they are not required (formally for urcu-mb and urcu-signal by model checking, less formally for urcu-qsbr by looking at the execution order of concurrent synchronize_rcu() and RCU read-sides with out-of-order load/stores). However, given that on the overall performance impact of synchronize_rcu(), these memory barriers do not add a significant overhead, let's leave them in place with a comment stating that they are not required. Signed-off-by: Mathieu Desnoyers --- diff --git a/urcu-qsbr.c b/urcu-qsbr.c index 25074d0..c678d38 100644 --- a/urcu-qsbr.c +++ b/urcu-qsbr.c @@ -124,8 +124,12 @@ static void update_counter_and_wait(void) * Enforce compiler-order of store to rcu_gp_ctr before before * load rcu_reader ctr. * This ensures synchronize_rcu() cannot be starved by readers. + * + * Adding a smp_mb() which is _not_ formally required, but makes the + * model easier to understand. It does not have a big performance impact + * anyway, given this is the write-side. */ - barrier(); + smp_mb(); /* * Wait for each thread rcu_reader_qs_gp count to become 0. diff --git a/urcu.c b/urcu.c index b856755..bb6629c 100644 --- a/urcu.c +++ b/urcu.c @@ -215,6 +215,10 @@ void update_counter_and_wait(void) */ /* + * Enforce compiler-order of store to rcu_gp_ctr before before + * load rcu_reader ctr. + * This ensures synchronize_rcu() cannot be starved by readers. + * * Adding a smp_mb() which is _not_ formally required, but makes the * model easier to understand. It does not have a big performance impact * anyway, given this is the write-side.