Update some comments
This commit is contained in:
parent
99bb2dda5d
commit
fba247b119
@ -330,33 +330,31 @@ bool sched_addreadytorun(FAR struct tcb_s *btcb)
|
||||
&g_cpu_irqlock);
|
||||
}
|
||||
|
||||
/* This CPU will be relinquishing the lock. But this works
|
||||
/* No.. This CPU will be relinquishing the lock. But this works
|
||||
* differently if we are performing a context switch from an
|
||||
* interrupt handler and the interrupt handler has established
|
||||
* a critical section. We can detect this case when
|
||||
* g_cpu_nestcount[me] > 0.
|
||||
*
|
||||
* REVISIT: Could this not cause logic to exit the critical section
|
||||
* prematurely in the context switch sequence?
|
||||
*/
|
||||
|
||||
else if (g_cpu_nestcount[me] <= 0)
|
||||
{
|
||||
/* No.. we may need to release our hold on the IRQ state. */
|
||||
/* Release our hold on the IRQ lock. */
|
||||
|
||||
spin_clrbit(&g_cpu_irqset, cpu, &g_cpu_irqsetlock,
|
||||
&g_cpu_irqlock);
|
||||
}
|
||||
|
||||
/* Sanity check. g_cpu_netcount should be greater than zero
|
||||
* only while we are within the critical section and within
|
||||
* an interrupt handler. If we are not in an interrupt handler
|
||||
* then there is a problem; perhaps some logic previously
|
||||
* called enter_critical_section() with no matching call to
|
||||
* leave_critical_section(), leaving the non-zero count.
|
||||
*/
|
||||
|
||||
else
|
||||
{
|
||||
/* Sanity check. g_cpu_netcount should be greater than zero
|
||||
* only while we are within the critical section and within
|
||||
* an interrupt handler. If we are not in an interrupt handler
|
||||
* then there is a problem; perhaps some logic previously
|
||||
* called enter_critical_section() with no matching call to
|
||||
* leave_critical_section(), leaving the non-zero count.
|
||||
*/
|
||||
|
||||
DEBUGASSERT(up_interrupt_context());
|
||||
}
|
||||
|
||||
|
@ -274,33 +274,31 @@ bool sched_removereadytorun(FAR struct tcb_s *rtcb)
|
||||
&g_cpu_irqlock);
|
||||
}
|
||||
|
||||
/* This CPU will be relinquishing the lock. But this works
|
||||
/* No.. This CPU will be relinquishing the lock. But this works
|
||||
* differently if we are performing a context switch from an
|
||||
* interrupt handler and the interrupt handler has established
|
||||
* a critical section. We can detect this case when
|
||||
* g_cpu_nestcount[me] > 0.
|
||||
*
|
||||
* REVISIT: Could this not cause logic to exit the critical section
|
||||
* prematurely in the context switch sequence?
|
||||
*/
|
||||
|
||||
else if (g_cpu_nestcount[me] <= 0)
|
||||
{
|
||||
/* No.. we may need to release our hold on the IRQ state. */
|
||||
/* Release our hold on the IRQ lock. */
|
||||
|
||||
spin_clrbit(&g_cpu_irqset, cpu, &g_cpu_irqsetlock,
|
||||
&g_cpu_irqlock);
|
||||
}
|
||||
|
||||
/* Sanity check. g_cpu_netcount should be greater than zero
|
||||
* only while we are within the critical section and within
|
||||
* an interrupt handler. If we are not in an interrupt handler
|
||||
* then there is a problem; perhaps some logic previously
|
||||
* called enter_critical_section() with no matching call to
|
||||
* leave_critical_section(), leaving the non-zero count.
|
||||
*/
|
||||
|
||||
else
|
||||
{
|
||||
/* Sanity check. g_cpu_netcount should be greater than zero
|
||||
* only while we are within the critical section and within
|
||||
* an interrupt handler. If we are not in an interrupt handler
|
||||
* then there is a problem; perhaps some logic previously
|
||||
* called enter_critical_section() with no matching call to
|
||||
* leave_critical_section(), leaving the non-zero count.
|
||||
*/
|
||||
|
||||
DEBUGASSERT(up_interrupt_context());
|
||||
}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user