On 03/11/2011 12:50, Paolo Bonzini wrote:
> On 11/03/2011 11:29 AM, Avi Kivity wrote:
>> > It would ensure that two mutators wouldn't run concurrently. In some
>> > sense, signal-safe code could then be considered thread-safe too.
>>
>> How so? The scheduler can switch between the two threads on every
>> instruction.
>
> In general signal-safe is more stringent than thread-safe, but with two
> exceptions: memory barriers and locked memory access. On x86 (implied by
> Windows...) you might also assume that the compiler will generate arithmetic
> operations with a memory destination, which makes code like
>
> void cpu_interrupt(CPUState *env, int mask)
> {
> env->interrupt_request |= mask; /* <--- this */
> cpu_unlink_tb(env);
> }
>
> signal-safe in practice---and even "thread-safe" on non-SMP systems. It's a
> huge assumption though, and I don't think it should be assumed anymore.
What can we do to improve that?
>
> With iothread the architecture of the QEMU main loop is anyway completely
> different.
>
Are you saying that things are better or worst with iothread?
--
Fabien Chouteau
