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
