From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYG1g-0002DW-SZ for qemu-devel@nongnu.org; Wed, 27 Aug 2008 04:05:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYG1f-0002C3-2V for qemu-devel@nongnu.org; Wed, 27 Aug 2008 04:05:12 -0400 Received: from [199.232.76.173] (port=53024 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYG1e-0002By-Sh for qemu-devel@nongnu.org; Wed, 27 Aug 2008 04:05:10 -0400 Received: from il.qumranet.com ([212.179.150.194]:57680) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KYG1e-0000uC-AM for qemu-devel@nongnu.org; Wed, 27 Aug 2008 04:05:10 -0400 Message-ID: <48B50AB4.7030806@qumranet.com> Date: Wed, 27 Aug 2008 11:05:08 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals. References: <1219336054-15919-1-git-send-email-kraxel@redhat.com> <18612.9061.534326.657959@mariner.uk.xensource.com> <48B42B57.2070301@qumranet.com> <200808261814.57044.jseward@acm.org> In-Reply-To: <200808261814.57044.jseward@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Julian Seward Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, Gerd Hoffmann Julian Seward wrote: > On Tuesday 26 August 2008, Avi Kivity wrote: > > >> Threading bugs in the implementation? In 2008? >> >> Practically all serious software is multithreaded nowadays. >> > > That's not in itself an argument in support of writing threaded code > if you don't have to. > > I spent much of the last year developing thread-checking tools > in the Valgrind framework (Helgrind), and testing them on serious > software. From that I would say that practically all serious > multithreaded software is riddled with threading bugs, mostly > data races and inconsistent lock orderings (potential deadlocks). > Most serious software has to be threaded. The absence of nonblocking libraries, the complexities of compositing nonblocking components when they do exist, and the requirement for utilizing multiple cores, all push towards threading. I agree that it's incredibly easy to write badly threaded code. But I don't see a way to avoid it. -- error compiling committee.c: too many arguments to function