From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:58991)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TXplz-0005AN-31
	for qemu-devel@nongnu.org; Mon, 12 Nov 2012 03:53:42 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TXplw-0005Bm-14
	for qemu-devel@nongnu.org; Mon, 12 Nov 2012 03:53:39 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39749)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TXplv-0005BZ-Ov
	for qemu-devel@nongnu.org; Mon, 12 Nov 2012 03:53:35 -0500
Message-ID: <50A0B907.1090304@redhat.com>
Date: Mon, 12 Nov 2012 09:53:27 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1352430870-10129-1-git-send-email-qemulist@gmail.com>
	<1352430870-10129-2-git-send-email-qemulist@gmail.com>
	<509DB2BB.1020202@redhat.com>
	<CAJnKYQ=fS6HqNnAG02sQgwRNhvWa_YJrRXMi5yfNQKy=dW-_Jg@mail.gmail.com>
In-Reply-To: <CAJnKYQ=fS6HqNnAG02sQgwRNhvWa_YJrRXMi5yfNQKy=dW-_Jg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC v1 1/3] bouce buffer has fine grain lock
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: liu ping fan <qemulist@gmail.com>
Cc: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>

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