[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v1 1/3] bouce buffer has fine grain lock
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC v1 1/3] bouce buffer has fine grain lock |
Date: |
Mon, 12 Nov 2012 09:53:27 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 |
Il 12/11/2012 07:23, liu ping fan ha scritto:
>> > Also, you do not need to keep the lock after address_space_map exits.
>> > In fact, it can be released as soon as bounce.buffer is written to.
>> > After that point, bounce will not be touched (the lock only serves to
>> > serialize writes to bounce.buffer). That is,
>> >
> But w/o the lock, the content in bounce.buffer for threadA, can be
> flushed with thread B.
It doesn't matter _which_ thread calls address_space_unmap. As long as
it's only one, you do not need a lock. In fact, it is perfectly fine
for thread A to call address_space_map and pass the address to thread B.
Thread B will later call address_space_unmap.
The important thing is that only one thread will call
address_space_unmap with buffer == bounce.buffer. So you do not need a
lock to serialize the writes in address_space_unmap.
See thread-pool.c for a similar trick:
/* Moving state out of THREAD_QUEUED is protected by lock. After
* that, only the worker thread can write to it. Reads and writes
* of state and ret are ordered with memory barriers.
*/
enum ThreadState state;
int ret;
...
qemu_mutex_lock(&lock);
...
req->state = THREAD_ACTIVE;
qemu_mutex_unlock(&lock);
req->ret = req->func(req->arg);
smp_wmb();
req->state = THREAD_DONE;
Paolo
[Qemu-devel] [RFC v1 3/3] make address_space_map safe, Liu Ping Fan, 2012/11/08