[Haskell-cafe] Haskell memory model

[Ben Lippmeier]

> On 5 Mar 2018, at 2:21 am, Li-yao Xia <lysxia at gmail.com> wrote:
> 
> What guarantees are there about shared memory concurrency in Haskell? In particular, I'm wondering how to correctly and efficiently synchronize mutable operations from the vector package, using stm or atomic-primops.
> 
> - Are reads/writes on vectors sequentially consistent? As a concrete example, can the following program (a common test for relaxed memory models) print anything?

Read/Writes for single elements of a vector compile down to single machine instructions, which will be some sort of vanilla MOV on x86. The x86 architecture is free to reorder stores after writes. AIUI this is due to the write buffer [2] which holds writes before they are committed to main memory. The x86 instruction set has an MFENCE operation to force loads and stores to be visible to global memory before others, but this isn’t inserted for read/writes to mutable vectors.

[1] https://en.wikipedia.org/wiki/Memory_ordering <https://en.wikipedia.org/wiki/Memory_ordering>
[2] https://en.wikipedia.org/wiki/Write_buffer <https://en.wikipedia.org/wiki/Write_buffer>


> - Do atomic operations (via stm or atomic-primops) imply some constraints between vector operations? 

I think the answer to this is “probably, but only incidentally”. The MFENCE instruction on x86 applies to all deferred load/store actions in the physical thread. If you can cause an MFENCE to be emitted into the instruction stream then this will also cause vector operations to be sequentialised.

See:
https://stackoverflow.com/questions/21506748/reasoning-about-ioref-operation-reordering-in-concurrent-programs <https://stackoverflow.com/questions/21506748/reasoning-about-ioref-operation-reordering-in-concurrent-programs>
http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/ <http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/>

Ben.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180305/db19a12b/attachment.html>