[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.5] rcu: Allow calling rcu_(un)register_thr
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH for-2.5] rcu: Allow calling rcu_(un)register_thread() during synchronize_rcu() |
Date: |
Mon, 27 Jul 2015 12:17:26 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 |
On 27/07/2015 04:24, Wen Congyang wrote:
> + /* Wait for one thread to report a quiescent state and try again.
> + * Release rcu_registry_lock, so rcu_(un)register_thread() doesn't
> + * wait too much time. Note: rcu_unregister_thread() may remove
> + * the node from qsreaders. That's a bit tricky, but it should work.
"It should work" is a bit optimistic. :D
Does this description look okay?
/* Wait for one thread to report a quiescent state and try again.
* Release rcu_registry_lock, so rcu_(un)register_thread() doesn't
* wait too much time.
*
* rcu_register_thread() may add nodes to ®istry; it will not
* wake up synchronize_rcu, but that is okay because at least another
* thread must exit its RCU read-side critical section before
* synchronize_rcu is done. The next iteration of the loop will
* process the new thread or set ->waiting for it. Hence, this can
* at worst cause synchronize_rcu() to wait for longer.
*
* rcu_unregister_thread() may remove nodes from &qsreaders instead
* of ®istry if it runs during qemu_event_wait. That's okay;
* the node then will not be added back to ®istry by QLIST_SWAP
* below. The invariant is that the node is part of one list when
* rcu_registry_lock is released.
*/
Paolo