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