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.
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
