From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJg1e-0007nk-MZ for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:52:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJg1Z-0003SO-IR for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:52:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJg1Z-0003S1-Dn for qemu-devel@nongnu.org; Mon, 27 Jul 2015 06:52:49 -0400 References: <55B59652.4090503@cn.fujitsu.com> <55B60536.4090006@redhat.com> <55B60B8A.3040703@cn.fujitsu.com> From: Paolo Bonzini Message-ID: <55B60D7C.4050100@redhat.com> Date: Mon, 27 Jul 2015 12:52:44 +0200 MIME-Version: 1.0 In-Reply-To: <55B60B8A.3040703@cn.fujitsu.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.5] rcu: Allow calling rcu_(un)register_thread() during synchronize_rcu() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang , qemu-devl On 27/07/2015 12:44, Wen Congyang wrote: > > * 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. > I don't understand this. The next iteration of the loop will move the new thread's > rcu_reader from registry to qsreaders even if we call rcu_read_lock() in the new thread. > Because rcu_gp_ongoing() will return false. You're right. This proves that a comment was necessary! :) Second try: * 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 * move the new thread's rcu_reader from ®istry to &qsreaders, * because rcu_gp_ongoing() will return false. Paolo