On 05.11.2013 20:03, deadalnix wrote:
On Tuesday, 5 November 2013 at 17:37:26 UTC, Simen Kjærås wrote:
Thank you, that's what I wanted to hear. I don't agree though.
Sequential consistence means reads and writes on one processor happen
in the order they're written, possibly interleaved with reads and
writes from other processors. I cannot see how this promise is broken
by taking a copy on which you only do reads.
No, that mean that read and write for ALL processor are done in order.
I believe you are thinking of strict consistency[0][1], not sequential
consistency[2][3].
In the former case, all reads are required to return the result of the
last write to that address. In the case of sequential consistency, it is
only necessary that each processor performs reads in the order they are
issued, and that each processor sees the results of other processors'
writes in the order in which they are issued.
From Lamport's original paper[4] on the subject: "the result of any
execution is the same as if the operations of all the processors were
executed in some sequential order, and the operations of each individual
processor appear in this sequence in the order specified by its program."
In essence, what I propose is a behavior equivalent to that the function
fuzz finish (essentially) instantaneously.
Without sequential consistency, CPU1 can see the operation of CPU2 in
the wrong order,
Indeed. Now, as I have shown, making a copy makes sure no such thing
will happen. Unless, as stated above, you mean strict consistency.
> as it won't ensure it is not working with outdated values.
Sequential consistency does not deal with absolutely outdated values,
only relatively outdated ones. That is, processor A is allowed to ignore
the actions of processor B until such a time that A feels like it.
However, when A does, it need also take into account all other actions
of processor B up until the time that processor B performed said action.
I especially suggest you read reference [3], as it shows very well that
two executions of the same sequentially consistent program may give
different results.
If you still disagree, I would love to be proven wrong. Please do
include a diagram of program state changes, as descriptions can be hard
to follow.
(Also, I'm aware this might come off as aggressive. No offense is
intended, and I *do* mean I'd love to be proven wrong, just in a way
that I learn from it)
[0]: http://en.wikipedia.org/wiki/Strict_consistency#Strict_consistency
[1]: http://cs.gmu.edu/cne/modules/dsm/orange/strict_con.html
[2]: http://en.wikipedia.org/wiki/Sequential_consistency
[3]:
http://www.e-reading.biz/chapter.php/143358/218/Tanenbaum_-_Distributed_operating_systems.html
[4]: http://research.microsoft.com/en-us/um/people/lamport/pubs/multi.pdf
--
Simen
