From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 2 02:25:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5C421065673 for ; Thu, 2 Aug 2012 02:25:08 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D0D9B8FC0C; Thu, 2 Aug 2012 02:25:08 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q722P7PJ046977; Thu, 2 Aug 2012 02:25:07 GMT (envelope-from listlog2011@gmail.com) Message-ID: <5019E500.8060105@gmail.com> Date: Thu, 02 Aug 2012 10:25:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Daniel Rudy References: <5019E209.50109@pacbell.net> In-Reply-To: <5019E209.50109@pacbell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Enumerating sleeping threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:25:09 -0000 On 2012/8/2 10:12, Daniel Rudy wrote: > Hello, > > What is the best way to enumerate the sleeping threads via > sleepqueue(9)? Furthermore, when enumerating the threads that are on > the run queue, what locks are needed, if any? sleepqueue hash bucket is private data structure in subr_sleepqueue.c, I think you can not access it outside of the file. One way to enumerate the sleeping threads is iterating all threads in the system, and check their states. proc.h contains two macros: FOREACH_PROC_IN_SYSTEM FOREACH_THREAD_IN_PROC To access thread state, you should use thread lock, call thread_lock() and thread_unlock(). thread lock is not fixed, it might be sleep-queue's spinlock or per-cpu runqueue lock, there even is a blocked spin-lock for intermediate state change. > Thank you. >