2014-11-18 04:40:55

by Srikanth Thokala

[permalink] [raw]
Subject: [PATCH] Documentation: memory-barriers: Fix typo in the first example

In the first example, the loads into 'x' and 'y' on CPU 2 doesn't
match the sequence of events described below it. To match the
sequence of events, the values of 'A' and 'B' should be loaded
into 'x' and 'y' respectively.

Signed-off-by: Srikanth Thokala <[email protected]>
---
Documentation/memory-barriers.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 22a969c..2770bce 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -115,8 +115,8 @@ For example, consider the following sequence of events:
CPU 1 CPU 2
=============== ===============
{ A == 1; B == 2 }
- A = 3; x = B;
- B = 4; y = A;
+ A = 3; x = A;
+ B = 4; y = B;

The set of accesses as seen by the memory system in the middle can be arranged
in 24 different combinations:
--
1.9.1


2014-11-27 06:49:30

by Srikanth Thokala

[permalink] [raw]
Subject: Re: [PATCH] Documentation: memory-barriers: Fix typo in the first example

Hi,

Kindly review the patch.

Thanks
Srikanth

On Tue, Nov 18, 2014 at 10:09 AM, Srikanth Thokala
<[email protected]> wrote:
> In the first example, the loads into 'x' and 'y' on CPU 2 doesn't
> match the sequence of events described below it. To match the
> sequence of events, the values of 'A' and 'B' should be loaded
> into 'x' and 'y' respectively.
>
> Signed-off-by: Srikanth Thokala <[email protected]>
> ---
> Documentation/memory-barriers.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 22a969c..2770bce 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -115,8 +115,8 @@ For example, consider the following sequence of events:
> CPU 1 CPU 2
> =============== ===============
> { A == 1; B == 2 }
> - A = 3; x = B;
> - B = 4; y = A;
> + A = 3; x = A;
> + B = 4; y = B;
>
> The set of accesses as seen by the memory system in the middle can be arranged
> in 24 different combinations:
> --
> 1.9.1
>

2014-12-02 21:15:22

by Jonathan Corbet

[permalink] [raw]
Subject: Re: [PATCH] Documentation: memory-barriers: Fix typo in the first example

On Thu, 27 Nov 2014 12:19:26 +0530
Srikanth Thokala <[email protected]> wrote:

> Hi,
>
> Kindly review the patch.

To me it looks right. Something like this, though, needs an ack from
Paul (cc'd) before I can be really confident. Paul...?

jon

> Thanks
> Srikanth
>
> On Tue, Nov 18, 2014 at 10:09 AM, Srikanth Thokala
> <[email protected]> wrote:
> > In the first example, the loads into 'x' and 'y' on CPU 2 doesn't
> > match the sequence of events described below it. To match the
> > sequence of events, the values of 'A' and 'B' should be loaded
> > into 'x' and 'y' respectively.
> >
> > Signed-off-by: Srikanth Thokala <[email protected]>
> > ---
> > Documentation/memory-barriers.txt | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> > index 22a969c..2770bce 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -115,8 +115,8 @@ For example, consider the following sequence of events:
> > CPU 1 CPU 2
> > =============== ===============
> > { A == 1; B == 2 }
> > - A = 3; x = B;
> > - B = 4; y = A;
> > + A = 3; x = A;
> > + B = 4; y = B;
> >
> > The set of accesses as seen by the memory system in the middle can be arranged
> > in 24 different combinations:
> > --
> > 1.9.1
> >
>

2014-12-02 21:50:17

by Paul E. McKenney

[permalink] [raw]
Subject: Re: [PATCH] Documentation: memory-barriers: Fix typo in the first example

On Tue, Dec 02, 2014 at 04:15:19PM -0500, Jonathan Corbet wrote:
> On Thu, 27 Nov 2014 12:19:26 +0530
> Srikanth Thokala <[email protected]> wrote:
>
> > Hi,
> >
> > Kindly review the patch.
>
> To me it looks right. Something like this, though, needs an ack from
> Paul (cc'd) before I can be really confident. Paul...?

I am guessing that this patch is against an old version of this file
(there have been two patches applied to this example in the last six
months). I believe that the current version is correct, in other words,
that Alexey Dobriyan and Pranith Kumar beat you to this one. ;-)

Please see below for the current version, which is in -tip as of
November 20th.

Thanx, Paul

> jon
>
> > Thanks
> > Srikanth
> >
> > On Tue, Nov 18, 2014 at 10:09 AM, Srikanth Thokala
> > <[email protected]> wrote:
> > > In the first example, the loads into 'x' and 'y' on CPU 2 doesn't
> > > match the sequence of events described below it. To match the
> > > sequence of events, the values of 'A' and 'B' should be loaded
> > > into 'x' and 'y' respectively.
> > >
> > > Signed-off-by: Srikanth Thokala <[email protected]>
> > > ---
> > > Documentation/memory-barriers.txt | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> > > index 22a969c..2770bce 100644
> > > --- a/Documentation/memory-barriers.txt
> > > +++ b/Documentation/memory-barriers.txt
> > > @@ -115,8 +115,8 @@ For example, consider the following sequence of events:
> > > CPU 1 CPU 2
> > > =============== ===============
> > > { A == 1; B == 2 }
> > > - A = 3; x = B;
> > > - B = 4; y = A;
> > > + A = 3; x = A;
> > > + B = 4; y = B;
> > >
> > > The set of accesses as seen by the memory system in the middle can be arranged
> > > in 24 different combinations:

For example, consider the following sequence of events:

CPU 1 CPU 2
=============== ===============
{ A == 1; B == 2 }
A = 3; x = B;
B = 4; y = A;

The set of accesses as seen by the memory system in the middle can be arranged
in 24 different combinations:

STORE A=3, STORE B=4, y=LOAD A->3, x=LOAD B->4
STORE A=3, STORE B=4, x=LOAD B->4, y=LOAD A->3
STORE A=3, y=LOAD A->3, STORE B=4, x=LOAD B->4
STORE A=3, y=LOAD A->3, x=LOAD B->2, STORE B=4
STORE A=3, x=LOAD B->2, STORE B=4, y=LOAD A->3
STORE A=3, x=LOAD B->2, y=LOAD A->3, STORE B=4
STORE B=4, STORE A=3, y=LOAD A->3, x=LOAD B->4
STORE B=4, ...
...

and can thus result in four different combinations of values:

x == 2, y == 1
x == 2, y == 3
x == 4, y == 1
x == 4, y == 3

2014-12-02 22:01:41

by Jonathan Corbet

[permalink] [raw]
Subject: Re: [PATCH] Documentation: memory-barriers: Fix typo in the first example

On Tue, 2 Dec 2014 13:50:06 -0800
"Paul E. McKenney" <[email protected]> wrote:

> I am guessing that this patch is against an old version of this file
> (there have been two patches applied to this example in the last six
> months). I believe that the current version is correct, in other words,
> that Alexey Dobriyan and Pranith Kumar beat you to this one. ;-)

I thought it looked familiar somehow...patch dropped.

I guess it's comforting to know that so many people are reading that file
so closely, but it's a little scary too...:)

Thanks,

jon

2014-12-02 22:09:45

by Paul E. McKenney

[permalink] [raw]
Subject: Re: [PATCH] Documentation: memory-barriers: Fix typo in the first example

On Tue, Dec 02, 2014 at 05:01:36PM -0500, Jonathan Corbet wrote:
> On Tue, 2 Dec 2014 13:50:06 -0800
> "Paul E. McKenney" <[email protected]> wrote:
>
> > I am guessing that this patch is against an old version of this file
> > (there have been two patches applied to this example in the last six
> > months). I believe that the current version is correct, in other words,
> > that Alexey Dobriyan and Pranith Kumar beat you to this one. ;-)
>
> I thought it looked familiar somehow...patch dropped.
>
> I guess it's comforting to know that so many people are reading that file
> so closely, but it's a little scary too...:)

What scares me is that so few people appear to have been reading it
earlier on. ;-)

Thanx, Paul

2014-12-03 00:15:57

by Måns Rullgård

[permalink] [raw]
Subject: Re: [PATCH] Documentation: memory-barriers: Fix typo in the first example

"Paul E. McKenney" <[email protected]> writes:

> On Tue, Dec 02, 2014 at 05:01:36PM -0500, Jonathan Corbet wrote:
>> On Tue, 2 Dec 2014 13:50:06 -0800
>> "Paul E. McKenney" <[email protected]> wrote:
>>
>> > I am guessing that this patch is against an old version of this file
>> > (there have been two patches applied to this example in the last six
>> > months). I believe that the current version is correct, in other words,
>> > that Alexey Dobriyan and Pranith Kumar beat you to this one. ;-)
>>
>> I thought it looked familiar somehow...patch dropped.
>>
>> I guess it's comforting to know that so many people are reading that file
>> so closely, but it's a little scary too...:)
>
> What scares me is that so few people appear to have been reading it
> earlier on. ;-)

Or they read it but failed to understand it. Not sure which is scarier.

Those are probably the Evil Vendor Tree developers who apparently think
"this is hard, best put volatile and barriers _everywhere_ and hope for
the best."

--
M?ns Rullg?rd
[email protected]

2014-12-03 00:27:39

by Paul E. McKenney

[permalink] [raw]
Subject: Re: [PATCH] Documentation: memory-barriers: Fix typo in the first example

On Wed, Dec 03, 2014 at 12:15:50AM +0000, M?ns Rullg?rd wrote:
> "Paul E. McKenney" <[email protected]> writes:
>
> > On Tue, Dec 02, 2014 at 05:01:36PM -0500, Jonathan Corbet wrote:
> >> On Tue, 2 Dec 2014 13:50:06 -0800
> >> "Paul E. McKenney" <[email protected]> wrote:
> >>
> >> > I am guessing that this patch is against an old version of this file
> >> > (there have been two patches applied to this example in the last six
> >> > months). I believe that the current version is correct, in other words,
> >> > that Alexey Dobriyan and Pranith Kumar beat you to this one. ;-)
> >>
> >> I thought it looked familiar somehow...patch dropped.
> >>
> >> I guess it's comforting to know that so many people are reading that file
> >> so closely, but it's a little scary too...:)
> >
> > What scares me is that so few people appear to have been reading it
> > earlier on. ;-)
>
> Or they read it but failed to understand it. Not sure which is scarier.
>
> Those are probably the Evil Vendor Tree developers who apparently think
> "this is hard, best put volatile and barriers _everywhere_ and hope for
> the best."

"This is hard!!! Let's go do some single-threaded programming!" ;-)

Thanx, Paul