From owner-svn-src-head@FreeBSD.ORG Sun Jun 16 11:49:10 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AAD163DB; Sun, 16 Jun 2013 11:49:10 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4E416A8; Sun, 16 Jun 2013 11:49:10 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p14so1360868vbm.18 for ; Sun, 16 Jun 2013 04:49:09 -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=AnVwRZvhsnpvnrfU+2RdhOauqO51auMpyKgtsgKscVg=; b=02SXNfcwioTqSH0t++XO0o+PheW4F5pr64APvzDZYvMDzKZYL5YjYyT2KFVJ18ntRL XFdVmlYxQ++zX/pVpw69Q8DkBNlPQyLbU+VZUdGazWzV6ZTI24DayCwbucXO7wxpkeMx no28NDq4rCl4HBGpJ12b18vHK+3sC0+gH3EO/5cjnJMDvoDa84pkEYR/BCvFPM/RNyHc WbqsJBB2W5C1jAMe75Am6ynkDE/oSKsqUL0nVBTJWsilVylEwA+Q2uC8bKpn5GT99z3x w6huRfqxCVTCHd6TAZvEc5aAHEk3KDr1sPsMMun/1IKEPnb7CBubZKMe1Wy2YKVYqco3 /5WQ== MIME-Version: 1.0 X-Received: by 10.58.198.44 with SMTP id iz12mr2190223vec.85.1371383349669; Sun, 16 Jun 2013 04:49:09 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.220.107.139 with HTTP; Sun, 16 Jun 2013 04:49:09 -0700 (PDT) In-Reply-To: <20130615125651.GH91573@alchemy.franken.de> References: <201306150821.r5F8Lst5089231@svn.freebsd.org> <20130615125651.GH91573@alchemy.franken.de> Date: Sun, 16 Jun 2013 13:49:09 +0200 X-Google-Sender-Auth: dgkWoVUqsjIpEJbvSIQOJLRhRjs Message-ID: Subject: Re: svn commit: r251782 - head/sys/sparc64/sparc64 From: Ed Schouten To: Marius Strobl Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 11:49:10 -0000 Hi Marius, 2013/6/15 Marius Strobl : > Semantically, this change is wrong; what we really need here is an > acquire variant. Using the release variant instead happens to also > work - albeit additionally wastes CPU cycles for the write memory > barrier - because in total store order, atomic operations implicitly > include the read memory barrier necessary for acquire semantics. In > other words, atomic(9) is in dare need of atomic_store_acq_(). I personally dislike the idea of extending the existing atomic(9) API. My long-term goal would be that we could just use C11 atomics instead of using our own home-grown API. If we can't express this using the atomic(9) API, I'd just like us to use instead. Reading up on the C11 standard (section 5.1.2.4), it seems that the abstract model of threads described does not allow stores to be a acquire operations. This does make sense, though. A load can of course not be a release operation. Because releases synchronize with acquires, a store being an acquire operation would have nothing to synchronize with. So I guess in this case we should solve it by using a relaxed store, followed by an acquire fence: http://80386.nl/pub/sparc64-atomic.txt Would that work for you? -- Ed Schouten