>
> OTOH, certainly doing an IO operation should cause a thread switch.
> In my limited use of the concurrency extension, I found it hard to
> write a dining philosophers program that behaved randomly. I had to
> throw yield's in all over the place. The `GHC-specific concurrency
> issues' of the hslibs documentation should have more discussion about
> when GHC pre-empts threads and how to control it.
>
> I could have a go myself, but I'm sure someone else with more
> experience could do a much better job.
>
here's the current story:
- a thread can be preempted at any heap check point.
The reschedule flag is actually only checked every 4k of
allocation, since it's too expensive to check it at
every allocation.
- the rescheduling timer runs on a 20ms granularity,
and the currently running thread will be preempted
at the soonest opportunity after the timer expires.
One problem is that it's possible to write code that doesn't allocate any
heap, and hence never yields. This is pretty rare, and only seems to happen
in nfib-ish programs, so we haven't worried about working around it yet (if
necessary, we could insert extra reschedule points in such code).
GHC versions prior to 4.08 didn't use the rescheduling timer, and hence
context switches happened after every 4k of allocation by the current
thread. This resulted in about 5000 context switches per second on average,
which was way too many (and is also unfair: a thread doing more allocation
got less of the CPU). I got a significant boost in performance in the web
server when I started using the timer instead.
Cheers,
Simon
