Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Feb 2012 16:51:00 -0800
From:      Chuck Swiger <cswiger@mac.com>
To:        "Desai, Kashyap" <Kashyap.Desai@lsi.com>
Cc:        freebsd-scsi@freebsd.org, freebsd-stable <freebsd-stable@freebsd.org>, "McConnell, Stephen" <Stephen.McConnell@lsi.com>
Subject:   Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited
Message-ID:  <FDA8B243-6E6F-458A-8B93-D863EC9785B2@mac.com>
In-Reply-To: <B2FD678A64EAAD45B089B123FDFC3ED72B96D34854@inbmail01.lsi.com>
References:  <B2FD678A64EAAD45B089B123FDFC3ED72B96D34836@inbmail01.lsi.com> <20120222191519.GT55074@deviant.kiev.zoral.com.ua> <B2FD678A64EAAD45B089B123FDFC3ED72B96D34854@inbmail01.lsi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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....)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FDA8B243-6E6F-458A-8B93-D863EC9785B2>