wangchdo commented on code in PR #17642:
URL: https://github.com/apache/nuttx/pull/17642#discussion_r2663306234
##########
sched/hrtimer/hrtimer_process.c:
##########
@@ -69,63 +70,69 @@
void hrtimer_process(uint64_t now)
{
FAR hrtimer_t *hrtimer;
- uint64_t expired;
- uint32_t period = 0;
irqstate_t flags;
+ hrtimer_cb func;
+ uint64_t expired;
+ uint64_t period = 0;
+ int cpu = this_cpu();
/* Lock the hrtimer RB-tree to protect access */
flags = spin_lock_irqsave(&g_hrtimer_spinlock);
/* Fetch the earliest active timer */
- hrtimer = (FAR hrtimer_t *)RB_MIN(hrtimer_tree_s, &g_hrtimer_tree);
+ hrtimer = hrtimer_get_first();
while (hrtimer != NULL)
{
+ func = hrtimer->func;
+
+ /* Ensure the timer callback is valid */
+
+ DEBUGASSERT(func != NULL);
+
+ expired = hrtimer->expired;
+
/* Check if the timer has expired */
- if (!clock_compare(hrtimer->expired, now))
+ if (!clock_compare(expired, now))
{
break;
}
/* Remove the expired timer from the active tree */
- RB_REMOVE(hrtimer_tree_s, &g_hrtimer_tree, &hrtimer->node);
-
- /* Ensure the timer callback is valid */
+ hrtimer_remove(hrtimer);
- DEBUGASSERT(hrtimer->func != NULL);
+ g_hrtimer_running[cpu] = hrtimer;
- hrtimer->state = HRTIMER_STATE_RUNNING;
+ /* Leave critical section before invoking the callback */
spin_unlock_irqrestore(&g_hrtimer_spinlock, flags);
/* Invoke the timer callback */
- period = hrtimer->func(hrtimer);
+ period = func(hrtimer);
+
+ /* Re-enter critical section to update timer state */
flags = spin_lock_irqsave(&g_hrtimer_spinlock);
- if ((hrtimer->state == HRTIMER_STATE_CANCELED) || (period == 0))
- {
- /* Timer is canceled or one-shot; mark it inactive */
+ g_hrtimer_running[cpu] = NULL;
- hrtimer->state = HRTIMER_STATE_INACTIVE;
- }
- else
+ /* Re-arm periodic timer if not canceled or re-armed concurrently */
+
+ if (period > 0 && hrtimer->expired == expired)
Review Comment:
checking `hrtimer->expired == expired` includes both below two checks:
1. `hrtimer->expired` being set to UINT64_MAX by` hrtimer_cancel()`
concurrently
2. `hrtimer->expired `being set to a new value by `hrtimer_start()`
concurrently and this new `hrtimer_start()` should win the competition
Do you think we need to consider the second case? If so i think we need to
keep the current implementation not changed, if not i will update according to
your suggestions. I think this is a design choice, and I think both are OK.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
