On Wed, Dec 13, 2017 at 06:43:58PM +0000, Stefan Hajnoczi wrote: > On Tue, Dec 05, 2017 at 01:51:49PM +0800, Peter Xu wrote: > > Monitor code now can be run in more than one thread. Let it be thread > > safe when accessing suspend_cnt counter. > > Please add doc comments to the functions explaining which thread they > may be called from (especially public functions). Without this > information other people will have a hard time keeping code thread-safe.
The two public functions would be monitor_resume() and monitor_suspend(). IIUC as long as these functions are using atomic operations correctly they should be able to be called anywhere? Could you help point out what I missed? > > > Signed-off-by: Peter Xu <pet...@redhat.com> > > --- > > monitor.c | 13 +++++++------ > > 1 file changed, 7 insertions(+), 6 deletions(-) > > From docs/devel/atomics.txt: > > Macros defined by qemu/atomic.h fall in three camps: > > - compiler barriers: barrier(); > > - weak atomic access and manual memory barriers: atomic_read(), > atomic_set(), smp_rmb(), smp_wmb(), smp_mb(), smp_mb_acquire(), > smp_mb_release(), smp_read_barrier_depends(); > > - sequentially consistent atomic access: everything else. > > The atomic_read() and atomic_set() calls in this patch aren't effective > without memory barriers. Please use atomic_mb_read() and > atomic_mb_set() instead. Will do. Thanks, -- Peter Xu
