RTS Scheduler Wiki-Page's description on Switching Context

[吴兴博]

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 <marlowsd at gmail.com>:

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




-- 
----------------
吴兴博