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: Torvald Riegel <triegel at redhat dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- Cc: Linus Torvalds <torvalds at linux-foundation dot org>, 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>, 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 12:07:02 +0100
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <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> <CA+55aFyi8QWge7QR0M+ABH-kEiwvoEyMhK6GWRvN1YNKJAFuSQ at mail dot gmail dot c!om> <1392737465 dot 18779 dot 7644 dot camel at triegel dot csb> <CA+55aFxn2KRXDQ91xRs=bO_6d_nA_PSQvoY1_=OxyJ86+KOO9Q at mail dot gmail dot com> <1392758516 dot 18779 dot 8378 dot camel at triegel dot csb> <20140218214713 dot GV14089 at laptop dot programming dot kicks-ass dot net>
On Tue, 2014-02-18 at 22:47 +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> > Yes, I do. But that seems to be "volatile" territory. It crosses the
> > boundaries of the abstract machine, and thus is input/output. Which
> > fraction of your atomic accesses can read values produced by hardware?
> > I would still suppose that lots of synchronization is not affected by
> > this.
>
> Its not only hardware; also the kernel/user boundary has this same
> problem. We cannot a-priory say what userspace will do; in fact, because
> we're a general purpose OS, we must assume it will willfully try its
> bestest to wreck whatever assumptions we make about its behaviour.
That's a good note, and I think a distinct case from those below,
because here you're saying that you can't assume that the userspace code
follows the C11 semantics ...
> We also have loadable modules -- much like regular userspace DSOs -- so
> there too we cannot say what will or will not happen.
>
> We also have JITs that generate code on demand.
.. whereas for those, you might assume that the other code follows C11
semantics and the same ABI, which makes this just a normal case already
handled as (see my other replies nearby in this thread).
> And I'm absolutely sure (with the exception of the JITs, its not an area
> I've worked on) that we have atomic usage across all those boundaries.
That would be fine as long as all involved parties use the same memory
model and ABI to implement it.
(Of course, I'm assuming here that the compiler is aware of sharing with
other entities, which is always the case except in those corner case
like accesses to (void*)0x123 magically aliasing with something else).