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

deadalnix deadalnix at gmail.com
Tue Nov 5 11:03:55 PST 2013


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.

> Example (CPU 1 is running fuzz, CPU 2 is randomly mutating 
> memory, or doing something worthwhile):
>
>   | CPU 1        | CPU 2
> ==============================
> 1 | read(arr)    | write(arr)
> 2 | read(arr[0]) | read(arr)
> 3 | read(arr[1]) | write(arr[0])
>
> Now, one sequentially consistent ordering of these operations 
> would be:
>
>   | CPU 1        | CPU 2
> ==============================
> 1 | read(arr)    |
> 2 | read(arr[0]) |
> 3 | read(arr[1]) |
> 4 |              | write(arr)
> 5 |              | read(arr)
> 6 |              | write(arr[0])
>
> Which is exactly what happens in the case of taking a copy.
>
> An equally valid ordering would of course be this:
>
>   | CPU 1        | CPU 2
> ==============================
> 1 | read(arr)    |
> 2 |              | write(arr)
> 3 |              | read(arr)
> 4 |              | write(arr[0])
> 5 | read(arr[0]) |
> 6 | read(arr[1]) |
>
> In which case the results would potentially be different. 
> However, the fact that other sequentially consistent orderings 
> exist does not mean that the first is wrong.
>

Without sequential consistency, CPU1 can see the operation of 
CPU2 in the wrong order, as it won't ensure it is not working 
with outdated values.


More information about the Digitalmars-d mailing list