Changes between Version 1 and Version 2 of Ticket #3838


Ignore:
Timestamp:
Jan 25, 2010 1:34:07 PM (5 years ago)
Author:
simonmar
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #3838 – Description

    v1 v2  
    2727 * If instead of blackholing the thunk we suspended it (ala `raiseAsync`), that would solve the problem.  It could be done in `threadPaused`, but how do we know when to do this? 
    2828 
    29  * Another solution along similar lines would be to just not blackhole the thunk at all: we let other threads evaluate it again.  This would make sense for thunks with a fixed known-small evaluation cost, such as selectors.  Unfortunately in this case the thunk in the `IORef` is not known to be small, although the two selector thunks also created by `atomicModifyIORef` do fall into this category. 
     29 * Another solution along similar lines would be to just not blackhole the thunk at all: we let other threads evaluate it again.  This would make sense for thunks with a fixed known-small evaluation cost, such as selectors.  Unfortunately in this case the thunk in the `IORef` is not known to be small, although the two selector thunks also created by `atomicModifyIORef` do fall into this category.  (Note however that blackholing is currently mandatory due to a problem that otherwise occurs in parallel GC: see `NOTE [upd-black-hole]` in [[GhcFile(rts/sm/Scav.c)]]). 
    3030 
    3131 * If we knew which threads owned which blackholes, then we could arrange to schedule threads on which others were blocked more quickly.  This is like a priority-inversion problem: one thread is blocking all the others, we need to increase its priority.  Unfortunately we don't have a mapping from blackholes to threads available, and maintaining it would introduce an overhead.  In this case we have a cascade of threads blocked on each other, so choosing the right scheduling is particularly difficult.