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: Paul McKenney <paulmck at linux dot vnet dot ibm dot com>
- Cc: Torvald Riegel <triegel at redhat 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: Thu, 27 Feb 2014 11:47:08 -0800
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <CA+55aFyjzR_Ga_HOKnBXpKYbuesqovj1-sFTVisD9UwA6JuJtw at mail dot gmail dot com> <20140223063426 dot GT4250 at linux dot vnet dot ibm dot com> <CA+55aFxMJvaQhoEwqgN=XA6gDOdZwoZQHdcAnB-FhAri_hK-6Q at mail dot gmail dot com> <CA+55aFw5tdjmNyHCdcyZ8NPpd1wCgOjLRzstRhp0Njs9azpi8Q at mail dot gmail dot com> <20140224172110 dot GO8264 at linux dot vnet dot ibm dot com> <CA+55aFyi45f7oaG4MYP41TOc=E8Ze8Om88dV2Lq4F=qebhxt4A at mail dot gmail dot com> <20140224185341 dot GU8264 at linux dot vnet dot ibm dot com> <CA+55aFzXyob0aKnv1u7Stbu0rH5Aq2jaA1rHb=TvQe9c1KY0oQ at mail dot gmail dot com> <1393515453 dot 28840 dot 9961 dot camel at triegel dot csb> <CA+55aFyE58NokYdoU+-feHTXv+5snByu+vCyMtg2fNc7npMbDg at mail dot gmail dot com> <20140227190611 dot GU8264 at linux dot vnet dot ibm dot com>
On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
>
> 3. The comparison was against another RCU-protected pointer,
> where that other pointer was properly fetched using one
> of the RCU primitives. Here it doesn't matter which pointer
> you use. At least as long as the rcu_assign_pointer() for
> that other pointer happened after the last update to the
> pointed-to structure.
>
> I am a bit nervous about #3. Any thoughts on it?
I think that it might be worth pointing out as an example, and saying
that code like
p = atomic_read(consume);
X;
q = atomic_read(consume);
Y;
if (p == q)
data = p->val;
then the access of "p->val" is constrained to be data-dependent on
*either* p or q, but you can't really tell which, since the compiler
can decide that the values are interchangeable.
I cannot for the life of me come up with a situation where this would
matter, though. If "X" contains a fence, then that fence will be a
stronger ordering than anything the consume through "p" would
guarantee anyway. And if "X" does *not* contain a fence, then the
atomic reads of p and q are unordered *anyway*, so then whether the
ordering to the access through "p" is through p or q is kind of
irrelevant. No?
Linus