clock_adjtime: use small lock to protect g_adjtime_ppb g_adjtime_wdog

[hujun260]

Summary

clock_adjtime: use small lock to protect g_adjtime_ppb g_adjtime_wdog
reason:
We would like to replace the critical section with a small lock.

Impact

clock_adjtime

Testing

ci ostest

[anchao]

line 119/123

[hujun260]

up_adjtime up_rtc_adjtime are only called in this file and all have been protected by g_adjtime_lock

[anchao]

What I mean is, you're not entirely sure how each lower half will implement these interfaces, right? If the up_xxx API has access to global variables, local spinlock may not guarantee that the underlying implementation has exclusive access to variables

[hujun260]

Addressing widely-used critical sections is not an easy task. now, we can analyze the issue case by case, considering that there is a limited number of up_xxx interfaces. We can examine the specific modifications or read operations of the up_xxx interfaces, as well as check whether the files they are located in use critical sections, to determine whether the modifications are safe.

[anchao]

We must ensure that each branch is safe. If all codes and variables are within the visible range, such modification is acceptable. Otherwise, please cautious.

[hujun260]

yes， If we remove the critical section protection for up_xxx, we should examine all the logic related to up_xxx to ensure there are no issues.

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR likely does not fully meet the NuttX requirements. While it provides some information, it's severely lacking in detail and completeness.

Here's a breakdown of the missing pieces:

• Summary: The "what" is described poorly. While it mentions replacing a critical section with a small lock, it doesn't explain why this is necessary (performance improvement, deadlock avoidance, etc.). It also lacks detail on how the change is implemented (what lock is used, how it integrates with existing code). There's no mention of related issues.

• Impact: This section is almost entirely empty. Simply stating "clock_adjtime" doesn't explain the impact. All the "NO/YES" questions need to be addressed with explanations if "YES". Consider things like: Will the change affect the accuracy of timekeeping? Will existing applications using clock_adjtime need to be modified? Are there any performance implications?

• Testing: "ci ostest" is insufficient. The request needs specific details:

  • Build Host(s): E.g., "Linux, x86_64, GCC 12.2.0"
  • Target(s): E.g., "qemu-rv32ima, sim:nsh"
  • Testing logs: Actual logs demonstrating the problem before the change and the improved behavior after the change. Simply saying "ci ostest" doesn't prove anything without the actual log output showing the difference.

In short, the PR needs significantly more information to be considered complete. It needs to clearly explain the motivation, the implementation details, the potential impact on various aspects of the system, and provide concrete evidence that the change works as intended.