[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/4] iothread: replace init_done_cond with a sem
From: |
Marc-André Lureau |
Subject: |
Re: [Qemu-devel] [PATCH 1/4] iothread: replace init_done_cond with a semaphore |
Date: |
Fri, 22 Feb 2019 10:44:27 +0100 |
Hi
On Fri, Feb 22, 2019 at 10:33 AM Paolo Bonzini <address@hidden> 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 <address@hidden> 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 <address@hidden>
> >>
> >> 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
[Qemu-devel] [PATCH 3/4] iothread: create main loop unconditionally, Peter Xu, 2019/02/21
[Qemu-devel] [PATCH 2/4] iothread: create the gcontext onconditionally, Peter Xu, 2019/02/21
[Qemu-devel] [PATCH 4/4] iothread: push gcontext earlier in the thread_fn, Peter Xu, 2019/02/21