qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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