site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Aug 26, 2009, at 12:57 PM, Terry Lambert 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? A non-platform-dependant question: does an "involuntary preemted" thread means that it was blocked by "someone else"? ;-) -- Jamison Hope The PTR Group www.theptrgroup.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Aug 26, 2009, at 4:31 AM, Esteban Bodigami <esteban.bodigami@gmail.com

wrote:

Terry Lambert <tlambert@apple.com>: On Aug 25, 2009, at 3:26 PM, Joel Reymont wrote: 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: 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!"). This email sent to site_archiver@lists.apple.com