What functions can be called on a shared struct that's implicitly castable to immutable?

[Simen Kjærås]

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