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

Simen Kjærås simen.kjaras at gmail.com
Tue Nov 5 19:06:52 PST 2013


On 06.11.2013 02:28, deadalnix wrote:
> 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.

Indeed not. That's why I've argued that it should depend only on the 
function definition (const, pure, and all arguments implicitly 
convertable to immutable).


>>> 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.

Then what are you even arguing? I'm asking if this is fine, and now it 
is? What are you saying is not fine, then?


The whole idea here is that making a copy and operating on that does not 
violate SC (see diagram in earlier post), and thus that calling a const 
pure function on a type that's implicitly convertable to immutable and 
that only takes arguments that are implicitly convertable to immutable 
is safe to implement as making a copy and operating on that.

I've asked you twice now to give an example of how this idea is wrong, 
and I've yet to see any evidence it is.

It is of course not the case that operating on the shared value without 
copying is safe - that's why I argue that copying is good.


>> 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.

I cannot for the life of me see how my suggestion violates SC, and you 
even seem to say it doesn't ("making a copy is fine"). Are you arguing 
about something other than what I'm arguing about?

-- 
   Simen


More information about the Digitalmars-d mailing list