On 19/05/2011 10:18, 吴兴博 wrote:
Thanks! Now I have sense about the switching.
There are more confusion. Please help me make it clear:)
See this words in the quotation:
"If the foreign call is short, we don't want to incur the cost of a
context switch on returning"
-> "but since we marked the Capability as free there's a good chance
the returning Task will be able to re-acquire it immediately and
continue."
So dose the "good chance" means "the re-schedule can make the T1 get
back ASAP, but OS-Thread's context switch cannot be avoided"
Or "a OS-thread context switch can be skipped".
I think the former is more close to the meaning of Wiki pages and your reply.
The OS thread context switch will still occur at some point after the
call has returned.
However, if many calls are taking place rapidly, then we don't get one
context switch per call, some of them will be aggregated. I fear I may
have confused you further now :)
Cheers,
Simon
regards!
2011/5/19 Simon Marlow<[email protected]>:
Let's say T1 is the running OS thread, and it is currently holding
Capability C. It makes a safe foreign call, so the scheduler releases C (C
is now marked free), and wakes up T2. Now, T1's call returns, T1 acquires C
again, and continues. Meanwhile, T2 will still wake up, observe that C is
not free, and sleep again. The two context switches are T1->T2 and T2->T1
(these are OS scheduler context switches, not RTS context switches).
I'm not sure if this is actually a problem in practice or not. I think we'd
need more instrumentation in ThreadScope to be able to analyse it. However
I *have* observed strange unexplained performance effects in the test
callback001 (http://darcs.haskell.org/nofib/smp/callback001).
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
