wangchdo commented on PR #17573: URL: https://github.com/apache/nuttx/pull/17573#issuecomment-3705451632
@cederom CI passed, could you please double check? @xiaoxiang781216 @Fix-Point I’ve addressed your comments—could you please take another look? I understand that your main concern with my previous implementation was about potential concurrency issues, or a possible violation of ownership invariants under SMP. This PR resolves those concerns using an approach that I believe is **reliable, simple, and efficient**. Below, I’ll explain the fix from a code-level perspective: 1. In `hrtimer_process()`, I now copy the **hrtimer callback**, `expiration time`, and `argument` into local variables while holding the spinlock:  2. Still in hrtimer_process(), the callback is invoked after the spinlock is released, using those local variables. This makes it safe for other cores to update the same hrtimer’s callback or expiration concurrently via `hrtimer_set()`, `hrtimer_cancel()`, or `hrtimer_start()`:  3. In `hrtimer_cancel()`, `hrtimer->expired` is set to `UINT64_MAX` to explicitly mark the hrtimer as cancelled:  4 In `hrtimer_start()`, `hrtimer->expired` is updated directly with the new expiration value:  5. Also in `hrtimer_process()`, if period > 0, the hrtimer is only allowed to restart when `hrtimer->expired` has not been modified concurrently by other cores. Both `hrtimer_cancel() `(which sets expired to UINT64_MAX) and `hrtimer_start() `(which sets it to a new value) will cause this check to fail. This guarantees that the **hrtimer will not be restarted unexpectedly**:  6. Finally, in` hrtimer_process()`, `hrtimer->cpus `acts as a reference counter and is automatically incremented and decremented. This allows it to be safely used by `hrtimer_cancel_sync() `to ensure the hrtimer is fully quiesced before returning:   **Overall, this design ensures correct behavior under SMP while keeping the logic straightforward and efficient, and it integrates cleanly with the existing hrtimer model in NuttX.** -- 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]
