[GHC] #15975: semantics of concurrent program depends on -O level, -f[no-]omit-yields

#15975: semantics of concurrent program depends on -O level, -f[no-]omit-yields -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Runtime | Version: 8.6.2 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am surprised by the behaviour of the program below (the interesting property is whether it will output "foo"). Behaviours (plural) actually: it seems to depend on optimisation level, on omit-yields, and on very small changes in the source code: It does print (mostly), when compiled with -O0. It does not, when compiled with -O2. With -O2 -fno-omit-yields, it will print. With -O0 -fno-omit-yields, and when I remove the two newTVar in the beginning, it will mostly not print. How come? These differences already occur with the last two lines replaced by "forever $ return ()", so the STM stuff may be inessential here. But that's the context where I came across the problem. See also discussion at https://mail.haskell.org/pipermail/haskell- cafe/2018-November/130274.html {{{ import Control.Concurrent.STM import Control.Concurrent ( forkIO ) import Control.Monad ( forever ) import System.IO main = do atomically $ newTVar "bar" atomically $ newTVar False forkIO $ putStrLn "foo" x <- atomically $ newTVar False forever $ atomically $ writeTVar x True }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15975 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15975: semantics of concurrent program depends on -O level, -f[no-]omit-yields -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Runtime System | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): (based on https://mail.haskell.org/pipermail/haskell- cafe/2018-November/130280.html ) So my implicit assumption was that a run of the transaction manager (because "atomically") is also a yield - but this example shows that it isn't. If this is indeed the case, then this deserves to be mentioned in the documentation of Control.Concurrent.STM ? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15975#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC