From owner-freebsd-stable@FreeBSD.ORG Thu Feb 23 00:51:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAD5106564A for ; Thu, 23 Feb 2012 00:51:02 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 820F58FC0A for ; Thu, 23 Feb 2012 00:51:02 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp030.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LZT00ABFMD13060@asmtp030.mac.com>; Wed, 22 Feb 2012 16:51:02 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-02-22_06:2012-02-21, 2012-02-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202220287 From: Chuck Swiger In-reply-to: Date: Wed, 22 Feb 2012 16:51:00 -0800 Message-id: References: <20120222191519.GT55074@deviant.kiev.zoral.com.ua> To: "Desai, Kashyap" X-Mailer: Apple Mail (2.1084) Cc: freebsd-scsi@freebsd.org, freebsd-stable , "McConnell, Stephen" Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 00:51:02 -0000 On Feb 22, 2012, at 4:22 PM, Desai, Kashyap wrote: > Just curious to know, What is a reason that thread can do blocking sleep but can't do unbounded sleep ? When you block, the scheduler can run other threads and only needs to wake up and run your thread after the blocking condition is completed. However, you don't want to busy-wait in a spin lock/mutex for any lengthy period of time. If your thread was allowed to do an unbounded sleep, especially in a fast interrupt handler context, what's going to wake it up? An NMI like the reset button [1]? :-) Regards, -- -Chuck [1]: Well, you could also call STI to permit clock interrupts or something else to fire an interrupt, but then your interrupt handler needs to be re-entrant. (And watch out for multiple nested interrupts blowing out the available stack space....)