github/esphome
2
0
Fork 0
mirror of https://github.com/esphome/esphome.git synced 2026-09-01 02:26:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

[api] Clarify fence comment per review

Browse Source 
Plain non-atomic load on the fast path is not a 'relaxed load' in the
C++ atomic sense; describe what the fence accomplishes instead.
This commit is contained in:
J. Nick Koston
2026-04-25 11:00:18 -05:00
parent df86f3aa0d
commit 4f51057fc2
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
esphome/core/application.h
+5 -4
View File
@@ -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