qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] qemu_mutex_iothread_locked not correctly syn


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2] qemu_mutex_iothread_locked not correctly synchronized
Date: Wed, 25 Nov 2015 15:36:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0


On 25/11/2015 15:04, David Engraf wrote:
>>>
>>
>> No, you don't.  Who is reading iothread_locked during
>> qemu_cond_wait_iothread?  No one, because it is a thread-local variable
>> whose address is never taken.
> 
> prepare_mmio_access is reading iothread_locked by using
> qemu_mutex_iothread_locked after qemu_tcg_wait_io_event calls
> qemu_cond_wait. All one the same thread.

Sure, but who has set iothread_locked to false during the execution of
qemu_cond_wait?  No one, because it's a thread-local variable.  If it's
true before qemu_cond_wait, it will be true after qemu_cond_wait and you
don't need qemu_cond_wait_iothread... unless your compiler is broken and
doesn't generate TLS properly.

Can you compile cpus.c with -S and attach it?

Paolo

> qemu_tcg_cpu_thread_fn
> -> qemu_tcg_wait_io_event
>    -> qemu_cond_wait acquires the mutex
> 
> qemu_tcg_cpu_thread_fn
> -> tcg_exec_all -> tcg_cpu_exec -> cpu_exec
> -> cpu_exec ends up in calling prepare_mmio_access



reply via email to

[Prev in Thread] Current Thread [Next in Thread]