On 19/05/2011 02:52, 吴兴博 wrote:
Hello everyone, I'm new to here, I had a question about RTS Scheduler.
When I read through the GHC Wiki commentary on the scheduler I was
confused about this section:
"""
One reason behind marking a Capability as free when it is handed
over is to support fast callouts.
When making a safe foreign call we have to release the Capability, and
therefore hand it over to
another worker thread. 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. The worker
that we woke up will find that the
Capability is owned, and go back to sleep again (this may incur a
double context switch if there are
no free CPUs on which to run the worker, however).
"""
My question is:
For the sentence in the parenthesis, what indeed will lead to the
"Double context switch", with or without marking a capability as free.
Furthermore, what are the two "switches" if they happen -- from who1
to who2, then who2 to who3?
Does "release the Cap" means there will be a re-schedule for
re-assigning the Cap, "make the Cap free" makes what different?
I had too much Questions on it since a was deeply confused:(
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).
Does that help?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
