Hi all,
I have a number of questions in regards to commit 6b07d38aaa520ce.
Given that the octeon doesn't reorder reads; the following:
" sync
ll ...
.
.
.
sc ...
.
.
sync
The second SYNC was redundant, but harmless. "
Still doesn't make sense, because if we need the first sync to stop
writes from being re-ordered with the ll-sc, we also need the second
sync to avoid the same.
Suppose:
STORE a
sync
LL-SC b
(not a sync)
STORE c
What avoids this becoming visible as:
a
c
b
?
Then there is:
" syncw;syncw
ll
.
.
.
sc
.
.
Has identical semantics to the first sequence, but is much faster.
The SYNCW orders the writes, and the SC will not complete successfully
until the write is committed to the coherent memory system. So at the
end all preceeding writes have been committed. Since Octeon does not
do speculative reads, this functions as a full barrier."
Read Documentation/memory-barrier.txt:TRANSITIVITY, the above doesn't
sound like syncw is actually multi-copy atomic, and therefore doesn't
provide transitivity, and therefore is not a valid sequence for
operations that are supposed to imply a full memory-barrier.
Please as to explain.
