[lttng-dev] Spin lock on URCU writers

[陳仁乾]

Hi all,

I wonder if it is safe to use a spin lock on RCU writers?
Here's the sample code:

#include <stdbool.h>
#include <stdatomic.h>

static atomic_bool lock;

void writer(...) {
  while (atomic_fetch_or(&lock, true)) {}  // spin lock
  // Update rcu guarded pointers (code omitted)
  synchronize_rcu(); // potential dead lock?
  atomic_store(&lock, false);
}

My concern is, in a classical RCU model, the code snippet above may
introduce a dead lock.
Assume we use the pseudo RCU implementation given in the linux kernel
manual:

	void rcu_read_lock(void) { }

	void rcu_read_unlock(void) { }

	void synchronize_rcu(void)
	{
		int cpu;

		for_each_possible_cpu(cpu)
			run_on(cpu);
	}

When we try to run `for_each_possible_cpu(cpu)`, wouldn't it stuck on the
writer's spin lock?

Here's my dead lock scenario.
We have two writer thread T1 T2, they executed in following order:
1. T1 enters writer(...), acquires the spin lock and set it to true
2. T2 enters writer(...), tries to acquire the spin lock but failed. It
spins on the while loop.
3. T1 finishes updating rcu guarded pointer.
4. T1 calls synchronize_rcu(), which should put T1 on each CPU
5. T1 couldn't run on the CPU T2 occupies, because it is in a spin lock.
Therefore we enters a dead lock.

Is this a possible scenario, or it is already addressed in practice?
Maybe the way I write the spin lock is incorrect? Do I have to write it in
this way?

while (atomic_fetch_or(&lock, true)) {
  rcu_thread_offline();
  // other candidates:
  // sched_yield();
  // rcu_quiescent_state();
}

Please help to advice,
Thanks!

Felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20170818/206d25b6/attachment.html>