On Wednesday, 6 November 2013 at 01:04:19 UTC, Simen Kjærås wrote:
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."
Yes, that is what sequential consistency is. It require both the
writer and the reader to cooperate for this to happen.
People often get confused by think the reader do not need to do
anything special as the MOV instruction on x86 have the needed
guarantee. Consider that thread a does :
arr[0] = newvalue0
arr[1] = newvalue1
thread 2 could see newvalue1 but not newvalue0 is no sequential
consistency is present.
Note that it will happen to work on x86, because of the strong
memory model of x86, but it is not something safe in the general
case and something we should rely on in language specs.
In essence, what I propose is a behavior equivalent to that the
function fuzz finish (essentially) instantaneously.
In this very specific case, the function does nothing, so it is
safe. But we don't want to define rules that depend on the
function implementation.
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.
No making a copy is fine and the case where you pass by value
(you make a copy) do indeed work as expected.
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.
I understand the difference. But as long as both require
cooperation of the 2 threads, it doesn't change much to our
discussion here. We also do not say that sequential consistency
will magically make the program correct. Simply that sequential
consistency is what D's shared qualifier ensure. If the shared is
somehow elided like you propose, then the compiler wont issue the
correct reads with the pure const function, and sequential
consistency won't be ensured anymore. This is not acceptable as
per spec, shared things are sequentially consistent.
