mirror of
https://github.com/esphome/esphome.git
synced 2026-09-02 19:16:06 +00:00
J. Nick Koston
c414cc393f
The _empty_() helpers (to_add_empty_, defer_empty_, to_remove_empty_) forced the lock path on ESPHOME_THREAD_MULTI_NO_ATOMICS by hardcoding `return false`. That made Scheduler::call() pay a FreeRTOS mutex round-trip for each of process_defer_queue_ / process_to_add / cleanup_ on every idle tick just to confirm "nothing to do". On the only NO_ATOMICS target (BK72xx — ARMv5TE, single-core), an aligned 32-bit load is atomic at the hardware level. Mark the three skip-work counters volatile so the compiler cannot cache or elide the read, and let _empty_() compare against zero directly. Writers still hold lock_ for any RMW — that invariant is unchanged. A stale 0 is benign: the counter is checked on every Scheduler::call() iteration, so a missed update is caught next tick. Same pattern as the NO_ATOMICS reads in time_64.cpp. On BK72xx at ~3100 iter/min with ~8us/mutex this reclaims roughly 75ms/min of main-loop overhead. Measured on BK7238/BK7231N while profiling alongside libretiny-eu/libretiny#360. ATOMICS and SINGLE paths are unchanged (SINGLE keeps plain uint32_t, no volatile-read overhead).
