sascha/esphome
1
0
Fork 0
mirror of https://github.com/esphome/esphome.git synced 2025-11-04 09:01:49 +00:00
Code Issues Releases Wiki Activity

[scheduler] Fix LibreTiny compilation error due to missing atomic operations (#9643)

Browse Source
This commit is contained in:
J. Nick Koston
2025-07-17 16:21:46 -10:00
committed by GitHub
parent 158a3b2835
commit a18ddd1169
2 changed files with 51 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
esphome/core/scheduler.cpp
View File

@@ -8,6 +8,7 @@
#include <algorithm>
#include <cinttypes>
#include <cstring>
#include <limits>
namespace esphome {
@@ -15,7 +16,7 @@ static const char *const TAG = "scheduler";
static const uint32_t MAX_LOGICALLY_DELETED_ITEMS = 10;
// Half the 32-bit range - used to detect rollovers vs normal time progression
static const uint32_t HALF_MAX_UINT32 = 0x80000000UL;
static constexpr uint32_t HALF_MAX_UINT32 = std::numeric_limits<uint32_t>::max() / 2;
// Uncomment to debug scheduler
// #define ESPHOME_DEBUG_SCHEDULER
@@ -273,7 +274,7 @@ void HOT Scheduler::call(uint32_t now) {
if (now_64 - last_print > 2000) {
last_print = now_64;
std::vector<std::unique_ptr<SchedulerItem>> old_items;
#if !defined(USE_ESP8266) && !defined(USE_RP2040)
#if !defined(USE_ESP8266) && !defined(USE_RP2040) && !defined(USE_LIBRETINY)
ESP_LOGD(TAG, "Items: count=%zu, now=%" PRIu64 " (%u, %" PRIu32 ")", this->items_.size(), now_64,
this->millis_major_, this->last_millis_.load(std::memory_order_relaxed));
#else
@@ -507,8 +508,49 @@ uint64_t Scheduler::millis_64_(uint32_t now) {
// This prevents race conditions at the rollover boundary without requiring
// 64-bit atomics or locking on every call.
#if !defined(USE_ESP8266) && !defined(USE_RP2040)
// Multi-threaded platforms: Need to handle rollover carefully
#ifdef USE_LIBRETINY
// LibreTiny: Multi-threaded but lacks atomic operation support
// TODO: If LibreTiny ever adds atomic support, remove this entire block and
// let it fall through to the atomic-based implementation below
// We need to use a lock when near the rollover boundary to prevent races
uint32_t last = this->last_millis_;
// Define a safe window around the rollover point (10 seconds)
// This covers any reasonable scheduler delays or thread preemption
static const uint32_t ROLLOVER_WINDOW = 10000; // 10 seconds in milliseconds
// Check if we're near the rollover boundary (close to std::numeric_limits<uint32_t>::max() or just past 0)
bool near_rollover = (last > (std::numeric_limits<uint32_t>::max() - ROLLOVER_WINDOW)) || (now < ROLLOVER_WINDOW);
if (near_rollover || (now < last && (last - now) > HALF_MAX_UINT32)) {
// Near rollover or detected a rollover - need lock for safety
LockGuard guard{this->lock_};
// Re-read with lock held
last = this->last_millis_;
if (now < last && (last - now) > HALF_MAX_UINT32) {
// True rollover detected (happens every ~49.7 days)
this->millis_major_++;
#ifdef ESPHOME_DEBUG_SCHEDULER
ESP_LOGD(TAG, "Detected true 32-bit rollover at %" PRIu32 "ms (was %" PRIu32 ")", now, last);
#endif
}
// Update last_millis_ while holding lock
this->last_millis_ = now;
} else if (now > last) {
// Normal case: Not near rollover and time moved forward
// Update without lock. While this may cause minor races (microseconds of
// backwards time movement), they're acceptable because:
// 1. The scheduler operates at millisecond resolution, not microsecond
// 2. We've already prevented the critical rollover race condition
// 3. Any backwards movement is orders of magnitude smaller than scheduler delays
this->last_millis_ = now;
}
// If now <= last and we're not near rollover, don't update
// This minimizes backwards time movement
#elif !defined(USE_ESP8266) && !defined(USE_RP2040)
// Multi-threaded platforms with atomic support (ESP32)
uint32_t last = this->last_millis_.load(std::memory_order_relaxed);
// If we might be near a rollover (large backwards jump), take the lock for the entire operation
@@ -540,7 +582,7 @@ uint64_t Scheduler::millis_64_(uint32_t now) {
}
#else
// Single-threaded platforms: No atomics needed
// Single-threaded platforms (ESP8266, RP2040): No atomics needed
uint32_t last = this->last_millis_;
// Check for rollover

8
esphome/core/scheduler.h
View File

@@ -4,7 +4,7 @@
#include <memory>
#include <cstring>
#include <deque>
#if !defined(USE_ESP8266) && !defined(USE_RP2040)
#if !defined(USE_ESP8266) && !defined(USE_RP2040) && !defined(USE_LIBRETINY)
#include <atomic>
#endif
@@ -211,11 +211,11 @@ class Scheduler {
// Both platforms save 40 bytes of RAM by excluding this
std::deque<std::unique_ptr<SchedulerItem>> defer_queue_; // FIFO queue for defer() calls
#endif
#if !defined(USE_ESP8266) && !defined(USE_RP2040)
// Multi-threaded platforms: last_millis_ needs atomic for lock-free updates
#if !defined(USE_ESP8266) && !defined(USE_RP2040) && !defined(USE_LIBRETINY)
// Multi-threaded platforms with atomic support: last_millis_ needs atomic for lock-free updates
std::atomic<uint32_t> last_millis_{0};
#else
// Single-threaded platforms: no atomics needed
// Platforms without atomic support or single-threaded platforms
uint32_t last_millis_{0};
#endif
// millis_major_ is protected by lock when incrementing, volatile ensures