This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH 0/5] arch: atomic rework
- From: Linus Torvalds <torvalds at linux-foundation dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Alec Teal <a dot teal at warwick dot ac dot uk>, Paul McKenney <paulmck at linux dot vnet dot ibm dot com>, Will Deacon <will dot deacon at arm dot com>, Peter Zijlstra <peterz at infradead dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, David Howells <dhowells at redhat dot com>, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, "akpm at linux-foundation dot org" <akpm at linux-foundation dot org>, "mingo at kernel dot org" <mingo at kernel dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 19 Feb 2014 11:49:10 -0800
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <20140207180216 dot GP4250 at linux dot vnet dot ibm dot com> <1391992071 dot 18779 dot 99 dot camel at triegel dot csb> <CA+55aFwTwCPMpYTL_vCgNNP0hE8s2sgB0iw-79=xoj99V0JUNA at mail dot gmail dot com> <1392183564 dot 18779 dot 2187 dot camel at triegel dot csb> <20140212180739 dot GB4250 at linux dot vnet dot ibm dot com> <CA+55aFw3S82GYdtnV2nJCvBGcuZf6kXdF5b7Vp9yb21QKr49Jw at mail dot gmail dot com> <20140213002355 dot GI4250 at linux dot vnet dot ibm dot com> <1392321837 dot 18779 dot 3249 dot camel at triegel dot csb> <20140214020144 dot GO4250 at linux dot vnet dot ibm dot com> <1392352981 dot 18779 dot 3800 dot camel at triegel dot csb> <20140214172920 dot GQ4250 at linux dot vnet dot ibm dot com> <CA+55aFx9CbgrfK4rBVYD75y2KoWiO90dSYsAW83O-tYVLK-gkg at mail dot gmail dot com> <CA+55aFypfiTFwundih8QEA6ZwVGk=g5L4sabsN0932eih5knOQ at mail dot gmail dot com> <1392486310 dot 18779 dot 6447 dot camel at triegel dot csb> <CA+55aFwTrt_6m1inNHQkk74i7uPkHNnacwHiBgioZSXieAs5Sw at mail dot gmail dot com> <1392666947 dot 18779 dot 6838 dot camel at triegel dot csb> <CA+55aFwUnRVk6q3VZeYjWfduoHcExW=Pht6jgp=4bBSaLHNPMA at mail dot gmail dot com> <530296CD dot 5050503 at warwick dot ac dot uk> <1392737465 dot 18779 dot 7644 dot camel at triegel dot csb> <1392758516 dot 18779 dot 8378 dot camel at triegel dot csb> <CA+55aFwOrFyDG_ZcOeh9Y-mQ1jMKA6bbBudh2hde6+jaRy4L_A at mail dot gmail dot com> <1392820858 dot 18779 dot 8936 dot camel at triegel dot csb>
On Wed, Feb 19, 2014 at 6:40 AM, Torvald Riegel <triegel@redhat.com> 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