From owner-freebsd-mips@FreeBSD.ORG Tue Jun 4 13:12:37 2013 Return-Path: Delivered-To: freebsd-mips@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 0963F4F1; Tue, 4 Jun 2013 13:12:37 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id B2EB01113; Tue, 4 Jun 2013 13:12:36 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wo10so310488obc.17 for ; Tue, 04 Jun 2013 06:12:36 -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=BVokO6MxSP+o73X/DQF48jeYhdomuymc4EyA8LVGtL8=; b=c8D/2l+kO9thxT0NpY8hUGAEDgFrxYHGam+k8cyFRMLhjP5UJ9ITURXtSHzPeSlc/f /rN/vsmIg8wiwr7Ll5Yz/vQpDK1j40FDJ9zcjiGYpxQ0HvHhZAk300Gs8HUHV7ndFqBG cO1bfcv99K3UAfFZle80rLt1VX0pQ0KOVRme06xxuhiy6L6/+Jg29KWl7cuFFsI/p6CS thHC5aybbKBY3PcUQliWm+I8FFasGpOUYcSt3+deN3CHPBjP1e/DXeA00FgBp23hNMij Sn7QxJzTAwtlscjeBcEQX2NXeCniJoKmcu1FWV+c+i+5xySwVXqRTPDDssemRhD0+++U /YQQ== MIME-Version: 1.0 X-Received: by 10.60.33.102 with SMTP id q6mr12334202oei.111.1370351556336; Tue, 04 Jun 2013 06:12:36 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.237.100 with HTTP; Tue, 4 Jun 2013 06:12:36 -0700 (PDT) In-Reply-To: <51ADA308.6040904@freebsd.org> References: <51ADA308.6040904@freebsd.org> Date: Tue, 4 Jun 2013 06:12:36 -0700 X-Google-Sender-Auth: UKda3lyyqPEvZiuB93DLOxsQkOM Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS From: mdf@FreeBSD.org To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Ed Schouten , freebsd-mips@freebsd.org, FreeBSD Arch X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:12:37 -0000 On Tue, Jun 4, 2013 at 1:19 AM, Andre Oppermann wrote: > On 03.06.2013 16:04, Ed Schouten wrote: > >> Hi, >> >> As of r251230, it should be possible to use C11 atomics in >> kernelspace, by including ! Even when not using Clang >> (but GCC 4.2), it is possible to use quite a large portion of the API. >> > > I'm a bit wary of *kernel* developers using C11-native atomics as opposed > to our own atomic API. This could lead to a proliferation of home-grown, > more or less correctly working, locks and variants thereof (mostly less > correct). > I don't understand this. > Atomics and locks are difficult enough to get right and reason about even > with our rather good API and I scream in fear thinking about everyone(tm) > doing their own "optimized" lock or even forgoing it because "it's atomic". > Why would we replace primitives that work? Meanwhile, the C11 atomics are at least as well documented as FreeBSD's, and they're standardized. Why should a future programmer, who understands C11 atomics, need to learn all new names to work on our OS? I would even propose to go as far as disbarring the use of C11 atomics in > the kernel other than inside the officially supported lock API. So compare and swap is hard to reason about? The C11 atomics should be no harder to reason about than our own -- their effects are documented. And we expect kernel programmers, of all people, to actually be careful about choosing their instructions. 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). Anyways, that aside, I see no reason to use a home-grown solution when the C standard finally provides one. It seems akin to preferring u_int64_t over uint64_t because we had it first and they changed the spelling on us. Thanks, matthew