Re: dtrace: catching thread yield
Re: dtrace: catching thread yield
- Subject: Re: dtrace: catching thread yield
- From: Jamison Hope <email@hidden>
- Date: Wed, 26 Aug 2009 13:27:36 -0400
On Aug 26, 2009, at 12:57 PM, Terry Lambert wrote:
On Aug 26, 2009, at 4:31 AM, Esteban Bodigami <email@hidden
> wrote:
Terry Lambert <email@hidden>:
On Aug 25, 2009, at 3:26 PM, Joel Reymont wrote:
I would like to get a kernel stack trace whenever a thread yields.
This may explain why the tread is yielding.
This is done with the sched provider on Solaris but is there a way
to do it on the Mac?
I thought of thread_yield_internal in the fbt provider but it
didn't
fire when tried.
Threads generally don't yield; they either block, or they are
involuntarily preempted. The following routines fbt probes will
correspond roughly to the following subset of sched provider
routines:
A non-platform-dependant question: does an "involuntary preemted"
thread means that it was blocked by "someone else"?
Threads can only be said to have been involuntarily prempted if they
are ready to run and aren't currently running.
Usually it's more "circumstances" than "someone else" that preempts
them. Like children in line for a slide in a playground, the ride
only last so long before they have to go wait in line again for
their next ride. A child can blame the other children for being
between them and their next ride, but it's not "someone" who caused
the ride to end at the end of the slide.
I suppose you could always blame gravity or blame the playground
designers for not figuring out how to fit an infinite number of
slides into a small playground so each child can have their own
slide and never have to wait in line.
They just need to have a taller slide so that the ratio of sliding
time to waiting time is improved. And they can make it a pipelined
slide so that multiple children can be in transit from top to bottom
simultaneously. The only problem is that if there's a blocking
instruction somewhere along the line (e.g. a fat kid gets stuck), it
may be difficult to flush the pipe safely. There would definitely be
advantages to having parallel slides, but you know that it's
inevitable that there would be a large degree of slide affinity which
would keep throughput well below the theoretical maximum ("But I don't
like this slide! I wanna go on the same slide that Tommy's on!").
;-)
--
Jamison Hope
The PTR Group
www.theptrgroup.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden