mirror of
https://github.com/esphome/esphome.git
synced 2026-07-10 17:05:36 +00:00
J. Nick Koston
6d1d924ff9
Two fixes Copilot flagged on #15947: 1. Use __atomic_load_n to re-read last_millis under the lock, not a plain read. The forward-progression branch (else if) writes last_millis with __atomic_store_n without holding lock, so the under-lock plain read would race with it and be UB in the C++ memory model. 2. Reload major from millis_major after acquiring the lock. The unlocked load at the top of the function can be stale by the time we get the lock: another thread may have completed a rollover between the unlocked load and the lock acquisition, leaving our local major behind by one. Without reload the function could return a 64-bit timestamp that jumps backwards by ~2^32 ms (~49.7 days). The MULTI_ATOMICS branch already handles this via its retry loop; NO_ATOMICS just reloads under the lock.
