From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 23 01:51:05 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 597F8106566B for ; Thu, 23 Feb 2012 01:51:05 +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 3D0DC8FC14 for ; Thu, 23 Feb 2012 01:51:04 +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-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 01:51:05 -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....)