[GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer

[GHC]

#16150: Data races in itimer_thread_func reported by ThreadSanitizer
-------------------------------------+-------------------------------------
        Reporter:  gnezdo            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Runtime System    |              Version:  8.4.4
      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 Phyx-):

 I believe #16147 is similar @bgamari, In that case there are multiple OS
 threads even on the non-threaded runtime. But the `ACQUIRE_LOCK` and
 `RELEASE_LOCK` macros expand to nothing on the non-threaded runtime, which
 introduces a race condition with shutdown of the loop and rts. Which is
 why I think it happens on the non-threaded but not the threaded.

 See https://ghc.haskell.org/trac/ghc/attachment/ticket/16147/sample.txt

 I think in this case we always want a lock, so `ACQUIRE_LOCK` and
 `RELEASE_LOCK` should be changed to `OS_ACQUIRE_LOCK` to
 `OS_RELEASE_LOCK`.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16150#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler