Hi On Fri, Feb 22, 2019 at 10:33 AM Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 22/02/19 07:36, Peter Xu wrote: > > On Fri, Feb 22, 2019 at 07:25:16AM +0100, Marc-André Lureau wrote: > >> Hi > >> > >> On Fri, Feb 22, 2019 at 4:14 AM Peter Xu <pet...@redhat.com> wrote: > >>> > >>> Only sending an init-done message using lock+cond seems an overkill to > >>> me. Replacing it with a simpler semaphore. > >>> > >>> Meanwhile, init the semaphore unconditionally, then we can destroy it > >>> unconditionally too in finalize which seems cleaner. > >>> > >>> Signed-off-by: Peter Xu <pet...@redhat.com> > >> > >> The lock is also protecting thread_id. > > > > IMHO it's fine because thread_id is only changed at the beginning of > > iothread_run where the caller will definitely wait for the thread_id > > to be generated. Here qemu_sem_post() should at least contain one > > write memory barrier there to make sure the waker will read the > > correct value after sem_wait() and then later on thread_id is never > > changed. > > Yes, qemu_sem_post() is a "release" operation. Anything that happens > before it is visible to the thread that does qemu_sem_wait().
ok > In fact, thread_id is accessed outside the lock in > iothread_instance_finalize, so Peter's change is overall an improvement. > finalize() stops the threadm though -- Marc-André Lureau
