From 4f51057fc207979dfff72249ccf0bbf1b9536286 Mon Sep 17 00:00:00 2001 From: "J. Nick Koston" Date: Sat, 25 Apr 2026 11:00:18 -0500 Subject: [PATCH] [api] Clarify fence comment per review Plain non-atomic load on the fast path is not a 'relaxed load' in the C++ atomic sense; describe what the fence accomplishes instead. --- esphome/core/application.h | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/esphome/core/application.h b/esphome/core/application.h index 415bc30c50..fa777188e7 100644 --- a/esphome/core/application.h +++ b/esphome/core/application.h @@ -571,10 +571,11 @@ inline ESPHOME_ALWAYS_INLINE Application::ComponentPhaseGuard::ComponentPhaseGua inline void ESPHOME_ALWAYS_INLINE Application::loop() { #if defined(USE_LWIP_FAST_SELECT) && defined(ESPHOME_THREAD_MULTI_ATOMICS) // Pairs with the TCP/IP thread's SYS_ARCH_UNPROTECT release on rcvevent so - // every Socket::ready() in this iter uses a relaxed load (no per-call memw). - // Wake is independent (xTaskNotifyGive/ulTaskNotifyTake), so non-losing. - // Skipped on MULTI_NO_ATOMICS (e.g. BK72xx) — that path keeps `volatile` in - // esphome_lwip_socket_has_data() instead. + // subsequent Socket::ready() checks in this iter observe the published state + // without a per-call memw. Wake is independent (xTaskNotifyGive/ + // ulTaskNotifyTake), so non-losing. Skipped on MULTI_NO_ATOMICS (e.g. + // BK72xx) — that path keeps `volatile` in esphome_lwip_socket_has_data() + // instead. std::atomic_thread_fence(std::memory_order_acquire); #endif #ifdef USE_RUNTIME_STATS