From owner-freebsd-mips@FreeBSD.ORG Tue Jun 4 17:23:35 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AB6276A; Tue, 4 Jun 2013 17:23:35 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx1.freebsd.org (Postfix) with ESMTP id BB3A3103D; Tue, 4 Jun 2013 17:23:34 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id gd11so390049vcb.25 for ; Tue, 04 Jun 2013 10:23:28 -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=IkW8ji4gMuhRowwT1AgRR6Wx2nP9CdEAmVAmPGh+zzI=; b=Yslk64yT7w6C3YN6aDro68PEvdUSdrVvg04zhrOTR/fDbO5bquJItSSpXsBJZlETJw C93ke1nlkjJ8wFZlZKo2YNgcf7M9M+Um6dxXrpEB8ndrWbn7sajKzcT/GLPLa+uCYotJ dp/RwBzrogAS7JM8WcO09U9+0faplHuCdfvlec3IJc+jHEp2cTWsudwRDMdpA1OgbuAU sIPCMlo61I3Q/OneI86ZKOTHHFHJzUIqBS1wdj5W4yYGhLzHnuldVn/WrdIF4BVcWpID o3p4pcWBdWdHK9RFG7837Hl6an1LsdFl0KVB0gY5UVll2BiijKP+4icjofPsLfhCVKrr L5vA== MIME-Version: 1.0 X-Received: by 10.221.4.131 with SMTP id oc3mr18813611vcb.49.1370366608682; Tue, 04 Jun 2013 10:23:28 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.220.107.139 with HTTP; Tue, 4 Jun 2013 10:23:28 -0700 (PDT) In-Reply-To: <20130604165652.GT3047@kib.kiev.ua> References: <51ADA308.6040904@freebsd.org> <201306040952.51513.jhb@freebsd.org> <20130604165652.GT3047@kib.kiev.ua> Date: Tue, 4 Jun 2013 19:23:28 +0200 X-Google-Sender-Auth: 3h2-NMjqZ9YUhjcB7SUcOmt4FZc Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS From: Ed Schouten To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Andre Oppermann , freebsd-mips@freebsd.org, John Baldwin , freebsd-arch@freebsd.org 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 17:23:35 -0000 2013/6/4 Konstantin Belousov : > I do not think so. The compilers are free to use whatever means to > implement the stdatomic. In particular, they are allowed to use simple > global lock to protect the 'atomic' access, see ATOMIC_type_LOCK_FREE > documented macros. Well, yes, no, it's complicated. The fact is, we are still free to implement without using those compiler's features. For example, we could have also decided to implement using only code we provide ourselves, as follows: static inline int8_t our_8bit_atomic_store(...) { ... } #define atomic_store(...) _Generic( \ int8_t: our_8bit_atomic_store(....), \ ... \ ) Also, it is extremely unlikely that compilers implement handlers for non-lock-free atomics themselves. Both Clang and GCC 4.7+, for example, will call into __atomic_*_{1,2,4,8,16,c}() whenever it does not know built-in CPU instructions to perform the operation. More details: http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary So in my opinion there are tons of ways we can still influence how the atomic operations are performed. The patch I sent out already demonstrates this, as we are free to implement the GCC intrinsics the way we like. -- Ed Schouten