From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoxzT-0001Fe-SO for qemu-devel@nongnu.org; Tue, 18 Jun 2013 11:38:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UoxzQ-0007In-AI for qemu-devel@nongnu.org; Tue, 18 Jun 2013 11:38:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoxzQ-0007IC-3U for qemu-devel@nongnu.org; Tue, 18 Jun 2013 11:38:36 -0400 From: Torvald Riegel In-Reply-To: <20130618145033.GN5146@linux.vnet.ibm.com> References: <1371381681-14252-1-git-send-email-pingfanl@linux.vnet.ibm.com> <1371381681-14252-2-git-send-email-pingfanl@linux.vnet.ibm.com> <51BF5C0F.6020209@twiddle.net> <51C05F88.2090308@redhat.com> <20130618145033.GN5146@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 18 Jun 2013 17:37:42 +0200 Message-ID: <1371569862.16968.23402.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: paulmck@linux.vnet.ibm.com Cc: Susmit.Sarkar@cl.cam.ac.uk, Andrew Haley , qemu-devel@nongnu.org, Liu Ping Fan , Anthony Liguori , luc.maranget@inria.fr, Paolo Bonzini , Peter.Sewell@cl.cam.ac.uk, Richard Henderson On Tue, 2013-06-18 at 07:50 -0700, Paul E. McKenney wrote: > First, I am not a fan of SC, mostly because there don't seem to be many > (any?) production-quality algorithms that need SC. But if you really > want to take a parallel-programming trip back to the 1980s, let's go! ;-) Dekker-style mutual exclusion is useful for things like read-mostly multiple-reader single-writer locks, or similar "asymmetric" cases of synchronization. SC fences are needed for this. > PS: Nevertheless, I personally prefer the C++ formulation, but that is > only because I stand with one foot in theory and the other in > practice. If I were a pure practitioner, I would probably strongly > prefer the Java formulation. That's because you're a practitioner with experience :)