#16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Following offline discussion with Ben Gamari and [https://mail.haskell.org/pipermail/ghc-devs/2018-November/016581.html Cmm Memory Model thread on ghc-devs@], I would like to propose to gradually transition RTS and Cmm to C11 memory model. There are multiple benefits: 1) Correctness: C11 atomics are properly specified and are easier to reason about than the existing SMP.h barriers. 2) Performance: compilers can optimize and generate better code for C11 atomics. For example, on ARMv8 acquire/release operations use specialized LDA/STL instructions. 3) Tooling support: once all code transitions to C11 atomics, tools like ThreadSanitizer can be used to find subtle data races. To make sure that code continues to compile with old compilers (pre C11), I plan to introduce wrapper functions (acquire_load, release_store, etc.) that are implemented either using C11 atomics or SMP.h barriers depending on the STDC_VERSION. Here is a [https://github.com/ulan/ghc/commit/0e8822a8038c3d0c770f4582c8f65b20d7823769 prototype implementation]. The idea is that newly written code should use the wrappers and we can gradually update the existing code. I think updating C code in RTS would work with this approach, but I am not sure about Cmm. Please let me know if you see potential issues, a better way to implement it, or oppose moving to C11 memory model. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16044 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler