Thank you, Paul!
I was wondering why in the following tutorial (section 4.4):
They were putting "if ( r1 == r1)" before "isync" and your explanation makes it less confusing.
What was (and somewhat still) confusing in Power ISA (v2.07) is the isync description:
"Executing an isync instruction ensures that all instructions preceding the isync instruction have completed before the isync instruction completes, and that no subsequent instructions are initiated until after the isync instruction completes."
The term "completes" I guess was understood by me as "committed", but according to your explanation, it only means that the instruction is deep enough in the pipeline to ensure it's successful commit in the future. And the same is with the phrase "no subsequent instructions are initiated until after the isync instruction completes". The term "completion" seems obscure to me.
But you did get my question perfectly precise and thank you once again!
вс, 22 июля 2018 г. в 19:37, Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>:
On Sun, Jul 22, 2018 at 06:42:45PM -0700, Artem Polyakov wrote:
> Hello,
> I have a question about the following scenario (considering POWER arch):
>
> initial { x = 0; y = 0; }
>
> thread0 {
> x = 1;
> lwsync;
> y = 1;
> }
>
> thread1 {
> a = y;
> isync;
> b = x;
> }
>
> Because "isync" is not a memory barrier this example doesn't have
> read/write barrier pairing. However, if I understand correctly, lwsync will
> ensure that "x = 1" will become visible to thread1 before lwsync is done
> and before "y = 1" will become visible. So "isync" here can be sort of
> control dependency as it ensures that "a = y" will be performed before "b =
> x" and even will flush the pipeline according to POWER9 spec.
>
> Can someone comment on this scenario and tell if I am right or where I am
> wrong.
I am not a Power hardware architect, but here is my understanding.
The isync waits until all the prior instructions "execute", but for
a limited definition of "execute". One way to think of isync is as
an instruction that does not allow subsequent instructions to start
until it can be proven that execution really will reach the isync
instruction.
So given a load, how could it be that execution would be prevented
from reaching the isync instruction? One possibility is a SEGV.
But once address translation completes successfully, SEGV cannot
happen. So isync doesn't need to wait for the load to return an
actual value, but instead only for its execution to reach a point
where the hardware knows that a value will eventually be returned.
And that is why you need a compare and conditional branch before the
isync to ensure that the load has completed. In that case, the
hardware cannot prove that execution will actually reach the isync
until the load completes, the compare sets the condition code,
and the branch condition is evaluated. Therefore, anything after
the compare-branch-isync series cannot start executing until after
the load returns its value.
Make sense, or am I missing the point of your question?
Thanx, Paul
