From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boRC5-00083w-5m for qemu-devel@nongnu.org; Mon, 26 Sep 2016 04:23:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1boRC4-0002Ib-5S for qemu-devel@nongnu.org; Mon, 26 Sep 2016 04:23:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boRC3-0002IG-Vu for qemu-devel@nongnu.org; Mon, 26 Sep 2016 04:23:20 -0400 References: <1474615909-17069-1-git-send-email-pbonzini@redhat.com> <1474615909-17069-17-git-send-email-pbonzini@redhat.com> <20d59fed-4187-28d2-c179-5e66571d5e49@twiddle.net> <1267831407.2636295.1474717973602.JavaMail.zimbra@redhat.com> <87a8evglwz.fsf@linaro.org> From: Paolo Bonzini Message-ID: <53158a4a-09f6-d01a-76af-69b349663bc9@redhat.com> Date: Mon, 26 Sep 2016 10:23:14 +0200 MIME-Version: 1.0 In-Reply-To: <87a8evglwz.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 16/16] cpus-common: lock-free fast path for cpu_exec_start/end List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: Richard Henderson , serge fdrv , cota@braap.org, qemu-devel@nongnu.org, sergey fedorov On 26/09/2016 09:28, Alex Benn=C3=A9e wrote: > > cpu->running is only read under the mutex, but can be written _by the > > owner thread only_ outside the mutex. So writes outside the mutex mu= st > > be atomic, but writes under the mutex don't because: > > > > - no other thread ever writes to cpu->running > > > > - no other thread can be reading cpu->running > > Should we add some comments to cpu.h's definitions to make the rules cl= ear? I don't know... It's awfully easy for such documentation to get out of=20 date. Currently it says: * @running: #true if CPU is currently running (lockless). * @has_waiter: #true if a CPU is currently waiting for the cpu_exec_end; * valid under cpu_list_lock. I think it's a good middle ground; it's kind of obvious that only the CPU itself writes cpu->running. I'm changing anyway the cpu->running assignment to atomic_set as suggested by Richard, and that makes it valid to read cpu->running outside the lock. Paolo