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. With iothread the architecture of the QEMU main loop is anyway
completely different.
Paolo
