From owner-freebsd-arch@FreeBSD.ORG Tue Jun 4 16:46:57 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D73DCCB5; Tue, 4 Jun 2013 16:46:57 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD731DA2; Tue, 4 Jun 2013 16:46:57 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id o17so332216oag.27 for ; Tue, 04 Jun 2013 09:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U321lJJP6z/A5sq5VfRFdvgFCaN/7LN+d3tIChXOn44=; b=H4T8tvGYva69xqc7cwInlVqQiZDqGTrTUY0L7df2COt5iEdFU2kcc//5leLt/pVmiS WQF9UNIqJLwtdYB6C1pgAN5o+CzBvec08NtgY+9X5Av1MkUpJL0SMQForPlAJcnHwFsY tofa+gGnTylaETpTjusWlX4J9D5HRvFcMwaRwq2jldD6JaK0RORx+7WYCiUMLRGJMwxF NPv+51mCe7AfGM5jmlI+Be+AwUi4fQv2i4plYxbdiusdYOYizZGfGAlmyVkt+w9Jw0Xn wxJ1fKJGnaWf3+HoxBkb9pyw1UhSg2aYU1pMCAo/tE/hT6NWm2Xmbs5q2PqV2sSavQyI MOrA== MIME-Version: 1.0 X-Received: by 10.60.79.231 with SMTP id m7mr12868216oex.105.1370364417114; Tue, 04 Jun 2013 09:46:57 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.237.100 with HTTP; Tue, 4 Jun 2013 09:46:57 -0700 (PDT) In-Reply-To: <201306040956.01065.jhb@freebsd.org> References: <51ADA308.6040904@freebsd.org> <201306040956.01065.jhb@freebsd.org> Date: Tue, 4 Jun 2013 09:46:57 -0700 X-Google-Sender-Auth: 4yIQmTIH3ETY_Ag5xxf_lyy1qnE Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Ed Schouten , Andre Oppermann , freebsd-mips@freebsd.org, FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:46:57 -0000 On Tue, Jun 4, 2013 at 6:56 AM, John Baldwin wrote: > On Tuesday, June 04, 2013 9:12:36 am mdf@freebsd.org wrote: > > Personally, I find both the C11 atomics and FreeBSD's > annoying, > > since "acquire" and "release" semantics are basically an x86 ism. PPC > has > > no notion of this; it has sync and isync and lwsync instructions which > are > > separate from the atomic set, but can be combined to create the same > > effect. Except the PPC manual is exceptionally explicit about what > > guarantees sync provides; it gives a mathematical ordering on > loads/stores > > i, j and which effects can be seen when. "Acquire" and "Release" seem to > > be named because you kinda need one to acquire a lock and kinda need one > to > > release it. But the effect of ordering loads or stores or both doesn't > > need to be dependent on the store/load, so putting the two together is > just > > an x86 convenience (and an annoyance on at least PPC). > > Actually, it came from ia64 (at least for FreeBSD's), not x86. :) However, > it is still useful to think about, and they are barriers with respect to > the > load/store of the lock cookie. The requirement that the "acquire" blocks > any > subsequent loads/stores in program order from occurring until after the > operation on the lock cookie succeeds and that "release" prevents any > loads/stores frmo moving past the operation on the lock cookie is not quite > the same as a traditional read or write barrier. acquire and release only > require a barrier in one direction and enforce ordering on both reads and > writes. Yeah, thinking more I feel sorry for those CISC architectures that need so many C primitives because it's less efficient to emit a memory fence then the load (or fence then store). It is less elegant, though, and the C standard had to add all the fenced variants of atomics to support it. Thanks, matthew