From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O6nIo-0001Uy-L8
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:06:26 -0400
Received: from [140.186.70.92] (port=39174 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O6nIm-0001Si-B7
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:06:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <tangchq@gmail.com>) id 1O6nIj-0007Kz-NU
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:06:22 -0400
Received: from mail-wy0-f173.google.com ([74.125.82.173]:48673)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <tangchq@gmail.com>) id 1O6nIj-0007KO-IY
	for qemu-devel@nongnu.org; Tue, 27 Apr 2010 12:06:21 -0400
Received: by wyb36 with SMTP id 36so2198389wyb.4
	for <qemu-devel@nongnu.org>; Tue, 27 Apr 2010 09:06:19 -0700 (PDT)
MIME-Version: 1.0
Date: Tue, 27 Apr 2010 12:06:17 -0400
Message-ID: <s2g50c1b8771004270906v69ad619cycc188f212fb0440a@mail.gmail.com>
From: "Chunqiang (CQ) Tang" <tangchq@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Qemu-devel] thread synchronization in qcow2.c and qcow2-cluster.c
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hi there,

I just started to read the code of qemu-kvm-0.12.3 recently, and was
puzzled by the thread synchronization issue in qcow2.c and
qcow2-cluster.c. Could someone please enlighten me? Thanks!

Specifically, I found that BDRVQcowState.cluster_allocs, which is a
QLIST_HEAD, may be accessed concurrently by two threads, but I could
not figure out how the two thread synchronize with each other to avoid
race conditions (e.g., through a lock?).

Stack trace of thread 1:
main -> main_loop -> kvm_main_loop -> main_loop_wait -> posix_aio_read
-> posix_aio_process_queue -> qcow_aio_write_cb ->
qcow2_alloc_cluster_offset (which may modify
BDRVQcowState.cluster_allocs)

Stack trace of thread 2:
ap_main_loop -> ... -> kvm_handle_io -> ... -> qcow_aio_writev ->
qcow_aio_write_cb -> qcow2_alloc_cluster_offset (which may modify
BDRVQcowState.cluster_allocs)

-- 
Best regards,
CQ Tang