jlaitine commented on code in PR #16673:
URL: https://github.com/apache/nuttx/pull/16673#discussion_r2275820165
##########
sched/sched/sched_unlock.c:
##########
@@ -69,28 +76,41 @@ void sched_unlock(void)
* then pre-emption has been re-enabled.
*/
- if (rtcb != NULL && --rtcb->lockcount == 0)
+ if (rtcb != NULL && rtcb->lockcount == 1)
{
irqstate_t flags = enter_critical_section_wo_note();
+ FAR struct tcb_s *ptcb;
+
+ rtcb->lockcount = 0;
/* Note that we no longer have pre-emption disabled. */
nxsched_critmon_preemption(rtcb, false, return_address(0));
sched_note_preemption(rtcb, false);
/* Release any ready-to-run tasks that have collected in
- * g_pendingtasks.
+ * g_pendingtasks (or in g_readytorun for SMP)
*
* NOTE: This operation has a very high likelihood of causing
* this task to be switched out!
*/
- if (list_pendingtasks()->head != NULL)
+#ifdef CONFIG_SMP
+ /* If this task is the lowest priority task running across all
+ * CPUs, there may be some higher priority task pending because
+ * of the sched lock.
+ */
+
+ ptcb = (FAR struct tcb_s *)dq_peek(list_readytorun());
+ if (ptcb && ptcb->sched_priority > rtcb->sched_priority &&
+ nxsched_select_cpu(ptcb->affinity) == rtcb->cpu &&
Review Comment:
> I need to still check if this check actually improves performance;
logically it is useless.
No, it is useless also performance-vice. Seems that calling the select_cpu
just eats the same amount of cycles as a potentially useless call to
nxsched_switch_running. So removed that. The previous "ptcb->sched_priority >
rtcb->sched_priority" is also just an optimization, having a measurable effect.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
