From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up7eI-0003k0-RH for qemu-devel@nongnu.org; Tue, 18 Jun 2013 21:57:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Up7eF-0000q3-RL for qemu-devel@nongnu.org; Tue, 18 Jun 2013 21:57:26 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:51739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up7eF-0000pq-Jo for qemu-devel@nongnu.org; Tue, 18 Jun 2013 21:57:23 -0400 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Jun 2013 19:57:23 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 8FDCF1FF001B for ; Tue, 18 Jun 2013 19:52:05 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5J1vJEn149584 for ; Tue, 18 Jun 2013 19:57:19 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5J1xivo016669 for ; Tue, 18 Jun 2013 19:59:44 -0600 Date: Tue, 18 Jun 2013 18:57:18 -0700 From: "Paul E. McKenney" Message-ID: <20130619015718.GZ5146@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> <51C085EF.1040303@redhat.com> <1371573518.16968.23603.camel@triegel.csb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1371573518.16968.23603.camel@triegel.csb> Subject: Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations) Reply-To: paulmck@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Torvald Riegel Cc: Andrew Haley , qemu-devel@nongnu.org, Liu Ping Fan , Anthony Liguori , Paolo Bonzini , Richard Henderson On Tue, Jun 18, 2013 at 06:38:38PM +0200, Torvald Riegel wrote: > On Tue, 2013-06-18 at 18:08 +0200, Paolo Bonzini wrote: > > Il 18/06/2013 16:50, Paul E. McKenney ha scritto: > > > 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. > > > > Awesome answer, and this last paragraph sums it up pretty well. > > I disagree that for non-Java code the Java model should be better. Both > C11 and C++11 use the same model, and I don't see a reason to not use it > if you're writing C/C++ code anyway. > > The C++ model is definitely useful for practitioners; just because it > uses seq-cst memory order as safe default doesn't mean that programmers > that can deal with weaker ordering guarantees can't make use of those > weaker ones. > I thought Paul was referring to seq-cst as default; if that wasn't the > point he wanted to make, I actually don't understand his theory/practice > comparison (never mind that whenever you need to reason about concurrent > stuff, having a solid formal framework as the one by the Cambridge group > is definitely helpful). Seq-cst and acq-rel are just different > guarantees -- this doesn't mean that one is better than the other; you > need to understand anyway what you're doing and which one you need. > Often, ensuring a synchronized-with edge by pairing release/acquire will > be sufficient, but that doesn't say anything about the Java vs. C/C++ > model. Having the Cambridge group's model and tooling around has definitely made my life much easier! And yes, I do very much see a need for a wide range of ordering/overhead tradeoffs, at least until such time as someone figures a way around either the atomic nature of matter or the finite speed of light. ;-) Thanx, Paul > > That was basically my understanding, too. I still do not completely > > get the relationship between Java semantics and ACQ_REL, but I can > > sidestep the issue for adding portable atomics to QEMU. QEMU > > developers and Linux developers have some overlap, and Java volatiles > > are simple to understand in terms of memory barriers (which Linux > > uses); hence, I'll treat ourselves as pure practitioners. > > I don't think that this is the conclusion here. I strongly suggest to > just go with the C11/C++11 model, instead of rolling your own or trying > to replicate the Java model. That would also allow you to just point to > the C11 model and any information / tutorials about it instead of having > to document your own (see the patch), and you can make use of any > (future) tool support (e.g., race detectors). > > > I will just not use __atomic_load/__atomic_store to implement the > > primitives, and always express them in terms of memory barriers. > > Why? (If there's some QEMU-specific reason, just let me know; I know > little about QEMU..) > I would assume that using the __atomic* builtins is just fine if they're > available. > > > Torvald >