[GHC] #8972: Investigate adding fast compare-and-swap Int type/primops

[GHC]

#8972: Investigate adding fast compare-and-swap Int type/primops
-------------------------------------+------------------------------------
        Reporter:  tibbe             |            Owner:  tibbe
            Type:  feature request   |           Status:  new
        Priority:  normal            |        Milestone:  7.10.1
       Component:  Compiler          |          Version:  7.9
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:  #8157, #7883
-------------------------------------+------------------------------------

Comment (by nominolo):

 Replying to [comment:6 rrnewton]:
 > I suspect the problem with atomicModifyIORef's poor behavior may have to
 do with blackholes?  Tracing ghc events will perturb these workloads a
 bunch I guess, but maybe threadscope could still tell us something wrt
 blackhole events.

 We were affected by this issue and looked at the thread status of all
 threads and noticed that they all get blocked on a blackhole. We suspect
 there are two issues here:

  1. Poor cache behaviour due to the CAS retry busy loop.
  2. All the threads get queued up waiting for the thread that currently
 owns the blackhole to get scheduled again.

 The second point is a potential issue for many other applications (e.g,.
 if a thread is holding on to an MVar). In the operating system world they
 deal with those kinds of issues either using:

  - interrupt blocking: i.e., a thread cannot be de-scheduled while holding
 the lock
  - time-slice donation / priority boosting: If a thread enters a critical
 section and still has some alotted compute time left, it "donates" that
 time to the thread owning the critical section, so that it will make
 progress and leave the critical section. If you have thread priorities
 then you can temporarily raise the priority of the thread in the critical
 section.  This rather complicated because priority boosting may have to be
 recursive (you have to boost to the priority of the highest-priority
 thread waiting), so not everyone likes this method.

 For GHC, I think it could be useful to have both mechanisms available.
 Marking a thread as non-interruptable could be exported from a "Here be
 dragons" module for using when you know that a thread will hold a
 lock/MVar only for a very short time.

 For thunks, when a thread blocks on a blackhole, the scheduler should
 probably then schedule that thread next. This way, the time spent
 evaluating a blackhole will be proportional to the number of threads
 waiting on it. I don't know if the reduced fairness causes issues here,
 though. You could mark a blackhole as "boosted" meaning, that as soon the
 blackhole is updated we not just wake up all threads in the run-queue, but
 also yield to the first thread in the blackhole.

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