sched/sched: add nxsched_wakeup(), introduce TSTATE_SLEEPING and improve nxsched_ticksleep()

[wangchdo]

This PR includes two commits:

commit 1:

    Add a new function nxsched_wakeup() to the scheduler,
    which allows waking up a sleeping task before its timeout.

commit 2:

    Refactor nxsched_timeout() to use nxsched_wakeup() in order to
    eliminate code duplication and improve maintainability.

Summary

Improved implementation of nxsched_ticksleep() and introduced new function nxsched_wakeup()

Impact

Improvement of newly added function nxsched_ticksleep() and introduced a new function nxsched_wakeup()

No impact to other nuttx functions

Testing

PR 17204 has already replace all Signal-based sleep implement to Scheduled sleep, So CI will verify this PR's improvement of nxsched_ticksleep() is OK

also,

on the one hand:
sleep related api test were added on sim/nsh, sabre-6quad/smp: nxsched_sleep() / nxsched_usleep() / nxsched_msleep() / nxsched_ticksleep()

on the other hand:
sched/event implementation has been modified to use sleep/wakeup pair, and the ostest including event test cases passed on board a2g-tc397-5v-tft:

[linguini1]

I think this needs to be tested with more than just CI. It is a code change that needs runtime testing, not just building.

Also, why would we want to wake up a sleeping task before its timeout? Maybe I'm unfamiliar with the semantics of sleeping, but isn't it a requirement that the caller is never woken up prior to the timeout? Only on or after?

[wangchdo]

I think this needs to be tested with more than just CI. It is a code change that needs runtime testing, not just building.

Also, why would we want to wake up a sleeping task before its timeout? Maybe I'm unfamiliar with the semantics of sleeping, but isn't it a requirement that the caller is never woken up prior to the timeout? Only on or after?

Sleep and wakeup sometimes should be in pair in terms of syncronization

For example task1 can not move on because some condition is not met and choose to sleep for a while in the simplest case, but before timeout task2 which has lower priority than task1 met the condition, then it can wakeup task1 to let task1 preempt it

sleep/wakeup is simpler and lighter than mutex, semaphore or event in this case

[wangchdo]

I think this needs to be tested with more than just CI. It is a code change that needs runtime testing, not just building.

Also, why would we want to wake up a sleeping task before its timeout? Maybe I'm unfamiliar with the semantics of sleeping, but isn't it a requirement that the caller is never woken up prior to the timeout? Only on or after?

I will add test it and put the results in this PR later

[linguini1]

Sleep and wakeup sometimes should be in pair in terms of syncronization

For example task1 can not move on because some condition is not met and choose to sleep for a while in the simplest case, but before timeout task2 which has lower priority than task1 met the condition, then it can wakeup task1 to let task1 preempt it

sleep/wakeup is simpler and lighter than mutex, semaphore or event in this case

But this isn't what sleeping is for? If you want to wait for a condition, you block on a semaphore/mutex, not sleep (unless it's some hardware polling condition that requires sleeping).

I personally don't support the addition of the wakeup function since now all the up_delay have been replaced with this new implementation, and up_delay would never return before the timeout. We're changing the behavior all over the code. This is a sleep function, not for waiting on a condition, just sleeping. I don't see a use case this is needed either, just use a semaphore.

[linguini1]

I personally don't support the addition of the wakeup function since now all the up_delay have been replaced with this new implementation, and up_delay would never return before the timeout. We're changing the behavior all over the code. This is a sleep function, not for waiting on a condition, just sleeping. I don't see a use case this is needed either, just use a semaphore.

I see now that even the previous implementation of nxsched_sleep could wake up the task early since it was implemented as waiting for a signal. So I do agree in that sense that this PR wouldn't necessarily change that behaviour. Although, I still think it shouldn't be possible to wake up a sleeping task before its timeout since that behaviour is not intuitive and doesn't seem correct for a delay/sleep function.

[wangchdo]

Sleep and wakeup sometimes should be in pair in terms of syncronization
For example task1 can not move on because some condition is not met and choose to sleep for a while in the simplest case, but before timeout task2 which has lower priority than task1 met the condition, then it can wakeup task1 to let task1 preempt it
sleep/wakeup is simpler and lighter than mutex, semaphore or event in this case

But this isn't what sleeping is for? If you want to wait for a condition, you block on a semaphore/mutex, not sleep (unless it's some hardware pulling condition that requires sleeping).

I personally don't support the addition of the wakeup function since now all the up_delay have been replaced with this new implementation, and up_delay would never return before the timeout. We're changing the behavior all over the code. This is a sleep function, not for waiting on a condition, just sleeping. I don't see a use case this is needed either, just use a semaphore.

HI @linguini1

I used this sleep/wakeup pair to improve event implementation in #17223
could you please help to review?