Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755060AbaBSTtO (ORCPT ); Wed, 19 Feb 2014 14:49:14 -0500 Received: from mail-vc0-f182.google.com ([209.85.220.182]:60324 "EHLO mail-vc0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754958AbaBSTtL (ORCPT ); Wed, 19 Feb 2014 14:49:11 -0500 MIME-Version: 1.0 In-Reply-To: <1392820858.18779.8936.camel@triegel.csb> References: <20140207180216.GP4250@linux.vnet.ibm.com> <1391992071.18779.99.camel@triegel.csb> <1392183564.18779.2187.camel@triegel.csb> <20140212180739.GB4250@linux.vnet.ibm.com> <20140213002355.GI4250@linux.vnet.ibm.com> <1392321837.18779.3249.camel@triegel.csb> <20140214020144.GO4250@linux.vnet.ibm.com> <1392352981.18779.3800.camel@triegel.csb> <20140214172920.GQ4250@linux.vnet.ibm.com> <1392486310.18779.6447.camel@triegel.csb> <1392666947.18779.6838.camel@triegel.csb> <530296CD.5050503@warwick.ac.uk> <1392737465.18779.7644.camel@triegel.csb> <1392758516.18779.8378.camel@triegel.csb> <1392820858.18779.8936.camel@triegel.csb> Date: Wed, 19 Feb 2014 11:49:10 -0800 X-Google-Sender-Auth: wOpIECDpv0Ru1H62_4BFxCItn14 Message-ID: Subject: Re: [RFC][PATCH 0/5] arch: atomic rework From: Linus Torvalds To: Torvald Riegel Cc: Alec Teal , Paul McKenney , Will Deacon , Peter Zijlstra , Ramana Radhakrishnan , David Howells , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "mingo@kernel.org" , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 19, 2014 at 6:40 AM, Torvald Riegel wrote: > > If all those other threads written in whichever way use the same memory > model and ABI for synchronization (e.g., choice of HW barriers for a > certain memory_order), it doesn't matter whether it's a hardware thread, > microcode, whatever. In this case, C11 atomics should be fine. > (We have this in userspace already, because correct compilers will have > to assume that the code generated by them has to properly synchronize > with other code generated by different compilers.) > > If the other threads use a different model, access memory entirely > differently, etc, then we might be back to "volatile" because we don't > know anything, and the very strict rules about execution steps of the > abstract machine (ie, no as-if rule) are probably the safest thing to > do. Oh, I don't even care about architectures that don't have real hardware atomics. So if there's a software protocol for atomics, all bets are off. The compiler almost certainly has to do atomics with function calls anyway, and we'll just plug in out own. And frankly, nobody will ever care, because those architectures aren't relevant, and never will be. Sure, there are some ancient Sparc platforms that only support a single-byte "ldstub" and there are some embedded chips that don't really do SMP, but have some pseudo-smp with special separate locking. Really, nobody cares. The C standard has that crazy lock-free atomic tests, and talks about address-free, but generally we require both lock-free and address-free in the kernel, because otherwise it's just too painful to do interrupt-safe locking, or do atomics in user-space (for futexes). So if your worry is just about software protocols for CPU's that aren't actually designed for modern SMP, that's pretty much a complete non-issue. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/