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

deadalnix deadalnix at gmail.com
Tue Nov 5 17:28:10 PST 2013


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.


More information about the Digitalmars-d mailing list