jlaitine commented on code in PR #16673:
URL: https://github.com/apache/nuttx/pull/16673#discussion_r2227827796
##########
sched/sched/sched_unlock.c:
##########
@@ -69,10 +69,12 @@ void sched_unlock(void)
* then pre-emption has been re-enabled.
*/
- if (rtcb != NULL && --rtcb->lockcount == 0)
Review Comment:
1) Now you anyhow take the critical section, and typically take it without
scheduling in between. There is no reason not to allow scheduling there, it is
better to run it always the same way
2) In the next patch I am using the information of the rtcb->cpu, which
might change if it schedules in between
So it is just cleaner to delay releasing the sched lock until inside the
critical section. Then it works the same way in 100% of the cases instead of
99.999% of the cases
Other than that, I am not sure if the current code would cause issues or
not. Testing such thing is close to impossible, it just looks scary.
And yes, removing the critical section in the future is a good idea! ( and
possibly removing the sched lock in semaphore code, would that be possible as
well? )
--
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
