Why sleeping not allowed after preempt_disable()

Hi,

Apologies for posting another trivial query. After reading about ISRs
and sleeping, I have cleared my doubts on why ISRs cannot sleep, but I
still cannot understand why a normal kernel thread cannot sleep once
it has disable preemption.

Assuming that the kernel thread does NOT hold any locks, nor any
per-cpu data, why stops it from sleeping after a call to
preempt_disable()?

TIA,

LL
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Why sleeping not allowed after preempt_disable()

------=_Part_15883_31725166.1179218658479
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

if you set disable preemption ... kernel can't schedule another thread until
thread itself leave the cpu ... if this thread sleeps who will wake it up
??? this would lead to deadlock ..
gaurav


On 5/15/07, Learning Linux wrote:
>
> Hi,
>
> Apologies for posting another trivial query. After reading about ISRs
> and sleeping, I have cleared my doubts on why ISRs cannot sleep, but I
> still cannot understand why a normal kernel thread cannot sleep once
> it has disable preemption.
>
> Assuming that the kernel thread does NOT hold any locks, nor any
> per-cpu data, why stops it from sleeping after a call to
> preempt_disable()?
>
> TIA,
>
> LL
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
>

------=_Part_15883_31725166.1179218658479
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Re: Why sleeping not allowed after preempt_disable()

if you set disable preemption ... kernel can't schedule another thread until
thread itself leave the cpu ... if this thread sleeps who will wake it up
??? this would lead to deadlock ..
gaurav

On 5/15/07, Learning Linux wrote:
> Hi,
>
> Apologies for posting another trivial query. After reading about ISRs
> and sleeping, I have cleared my doubts on why ISRs cannot sleep, but I
> still cannot understand why a normal kernel thread cannot sleep once
> it has disable preemption.
>
> Assuming that the kernel thread does NOT hold any locks, nor any
> per-cpu data, why stops it from sleeping after a call to
> preempt_disable()?
>
> TIA,
>
> LL
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Why sleeping not allowed after preempt_disable()

2007/5/15, Gaurav Bhatnagar :
> if you set disable preemption ... kernel can't schedule another thread until
> thread itself leave the cpu ... if this thread sleeps who will wake it up
> ??? this would lead to deadlock ..
> gaurav
>

I do not think the potential dead-lock is the reason, because the
sleep operation is exactly the operation of relinquishing CPU. So if a
process disable preemption and then sleep, the scheduler will be
invoked and another process will use CPU. No dead-lock here.

I think the reason lies in why you are about to use preemption
disabling in the first place. When you use preemption disabling, you
managed to define a critical region within which your data structure
is protected from being corrupted by another process. But if you put a
sleep in that critical region, I think you actually split your
original critical region into two regions in purpose so you should
encompass each region by one pair of preempt_disable/enable
respectively.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs