site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Russ noted off-list that the problem was resolved by 10.5.3. Wade _______________________________________________ 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... I'm not aware of anything that would cause the symptoms you're seeing that wasn't a result of contention; in the case where you have a core idle, what is your worker thread blocking on? "semaphore_timedwait_trap" is the mach incall that blocks a thread waiting for a semaphore wakeup, so you are blocking "legitimately". You might consider instrumenting your blocking points to see whether you spend an unexpectedly long time blocked at any given point - it sounds as though you expect to be running 8 threads non-stop, so it should be fairly straightforward to tell the difference between a legitimate and non-legit block. You should also check to make sure you aren't triggering any page-in/ out activity, as "tens of ms" is consistent with disk/network I/O timing. If you are handling multiple work units in a given run, it sounds like you might have a race between the work provider and consumers leading to a unit stuck in the queue. In the case where you have a thread asleep, have you checked the state of your work units? All this and more is provided in a System Trace, using Shark. Which Russ noted he already did. Without seeing the session, though, or at least the callstack for the blocking semaphore_timedwait_trap calls, there's not much point conjecturing. This email sent to site_archiver@lists.apple.com