Update some comments

This commit is contained in:
Gregory Nutt 2017-01-13 16:32:09 -06:00
parent 99bb2dda5d
commit fba247b119
2 changed files with 22 additions and 26 deletions

View File

@ -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());
}

View File

@ -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());
}