From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uovtk-0003lT-5Q for qemu-devel@nongnu.org; Tue, 18 Jun 2013 09:24:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uovte-0001Ad-Pe for qemu-devel@nongnu.org; Tue, 18 Jun 2013 09:24:36 -0400 Received: from mail-yh0-x22f.google.com ([2607:f8b0:4002:c01::22f]:45162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uovte-0001AY-Ks for qemu-devel@nongnu.org; Tue, 18 Jun 2013 09:24:30 -0400 Received: by mail-yh0-f47.google.com with SMTP id f64so1504385yha.34 for ; Tue, 18 Jun 2013 06:24:30 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51C05F88.2090308@redhat.com> Date: Tue, 18 Jun 2013 15:24:24 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <51BF5C0F.6020209@twiddle.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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: Richard Henderson Cc: Torvald Riegel , Andrew Haley , Liu Ping Fan , qemu-devel@nongnu.org, Anthony Liguori , "Paul E. McKenney" Il 17/06/2013 20:57, Richard Henderson ha scritto: >> + * And for the few ia64 lovers that exist, an atomic_mb_read is a ld.acq, >> + * while an atomic_mb_set is a st.rel followed by a memory barrier. > ... >> + */ >> +#ifndef atomic_mb_read >> +#if QEMU_GNUC_PREREQ(4, 8) >> +#define atomic_mb_read(ptr) ({ \ >> + typeof(*ptr) _val; \ >> + __atomic_load(ptr, &_val, __ATOMIC_SEQ_CST); \ >> + _val; \ >> +}) >> +#else >> +#define atomic_mb_read(ptr) ({ \ >> + typeof(*ptr) _val = atomic_read(ptr); \ >> + smp_rmb(); \ >> + _val; \ > > This latter definition is ACQUIRE not SEQ_CST (except for ia64). Without > load_acquire, one needs barriers before and after the atomic_read in order to > implement SEQ_CST. The store-load barrier between atomic_mb_set and atomic_mb_read are provided by the atomic_mb_set. The load-load barrier between two atomic_mb_reads are provided by the first read. > So again I have to ask, what semantics are you actually looking for here? So, everything I found points to Java volatile being sequentially consistent, though I'm still not sure why C11 suggests hwsync for load seq-cst on POWER instead of lwsync. Comparing the sequences that my code (based on the JSR-133 cookbook) generate with the C11 suggestions you get: Load seqcst hwsync; ld; cmp; bc; isync Store seqcst hwsync; st (source: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html) Load Java volatile ld; lwsync Store Java volatile lwsync; st; hwsync (source: http://g.oswego.edu/dl/jmm/cookbook.html) where the lwsync in loads acts as a load-load barrier, while the one in stores acts as load-store + store-store barrier. Is the cookbook known to be wrong? Or is Java volatile somewhere between acq_rel and seq_cst, as the last paragraph of http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile seems to suggest? Paolo