hujun260 commented on code in PR #18284:
URL: https://github.com/apache/nuttx/pull/18284#discussion_r2752668213
##########
sched/clock/clock_sched_ticks.c:
##########
@@ -62,13 +64,13 @@ static volatile clock_t g_system_ticks =
INITIAL_SYSTEM_TIMER_TICKS;
void clock_increase_sched_ticks(clock_t ticks)
{
+ irqstate_t flags;
+
/* Increment the per-tick scheduler counter */
-#ifdef CONFIG_SYSTEM_TIME64
- atomic64_fetch_add((FAR atomic64_t *)&g_system_ticks, ticks);
-#else
- atomic_fetch_add((FAR atomic_t *)&g_system_ticks, ticks);
-#endif
+ flags = write_seqlock_irqsave(&g_system_tick_lock);
Review Comment:
> Furthermore, the code already considers reading intermediate states and
compares the differences before and after, so I don't believe the bug you
mentioned exists.
Let me give you an example.
Suppose the 64-bit variable g_system_ticks is transitioning from 0xFFFFFFFF
to 0x100000000.
In memory, g_system_ticks would be composed of two 32-bit variables:
g_system_ticks_H and g_system_ticks_L.
The sequence of changes might look like this:
1 g_system_ticks_H: 0x0, g_system_ticks_L: 0xFFFFFFFF
2 g_system_ticks_H: 0x0, g_system_ticks_L: 0x0 (This is the intermediate
state)
3 g_system_ticks_H: 0x1, g_system_ticks_L: 0x0
If we read the value during this intermediate state, the result would be 0,
which is obviously incorrect.
--
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]
