RTS Scheduler Wiki-Page's description on Switching Context

[Simon Marlow]

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