[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 16/16] cpus-common: lock-free fast path for cpu_
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 16/16] cpus-common: lock-free fast path for cpu_exec_start/end |
Date: |
Mon, 26 Sep 2016 10:23:14 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
On 26/09/2016 09:28, Alex Bennée 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 must
> > 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 clear?
I don't know... It's awfully easy for such documentation to get out of
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
- Re: [Qemu-devel] [PATCH 15/16] tcg: Make tb_flush() thread safe, (continued)
[Qemu-devel] [PATCH 12/16] cpus-common: remove redundant call to exclusive_idle(), Paolo Bonzini, 2016/09/23
Re: [Qemu-devel] [PATCH v8 00/16] cpu-exec: Safe work in quiescent state, Alex Bennée, 2016/09/25