fix: lock CPU power history swap

[davidberenstein1957]

Description

Fixes a lost-update race on CPU._power_history. The 1 Hz monitor scheduler thread (CPU.monitor_power) appends to it, and the measure_power_secs scheduler thread (CPU.total_power) drains it. The read-then-rebind in total_power was not atomic, so a sample appended between the list comprehension and self._power_history = [] was dropped.

CPU now has a threading.Lock (_power_history_lock), held only for the O(1) list swap. _get_power_from_cpus() still runs outside the lock in both paths, so a slow backend (for example the IntelPowerGadget subprocess) never blocks the monitor thread. The unreachable if not power_history_in_W: branch is removed, since a sample is always appended before the average is taken.

Related Issue

Fixes #1315

Motivation and Context

In cpu_load mode the reported cpu_power is the mean of the buffered samples. The samples lost in the unlocked swap window are the ones taken while a slow measurement is in flight, so the error is small but systematic and silent.

How Has This Been Tested?

Two tests in tests/test_cpu_load.py::TestCPULoad:

• test_cpu_total_power_keeps_samples_added_while_draining: holds cpu._power_history_lock while monitor_power() runs on another thread, checks the monitor waits instead of appending, and that the sample is in the history once the lock is released.
• test_cpu_sample_appended_right_after_the_swap_goes_to_next_window: wraps the real lock so a 100 W monitor_power() sample fires right after the swap, and checks the first total_power() averages the old window (5.5 W) and the second picks up the 100 W sample (50.5 W).

CI is green on this branch.

Screenshots (if appropriate):

N/A

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

AI Usage Disclosure

• 🟥 AI-vibecoded
• 🟠 AI-generated
• ⭐ AI-assisted
• ♻️ No AI used

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the docs/how-to/contributing.md document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.74%. Comparing base (e5e46ab) to head (44ef635).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1335      +/-   ##
==========================================
+ Coverage   91.70%   91.74%   +0.04%     
==========================================
  Files          49       49              
  Lines        5157     5160       +3     
==========================================
+ Hits         4729     4734       +5     
+ Misses        428      426       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[benoit-cty]

🤖 This review comment was written and posted by Claude Opus 5.5 (AI assistant), at the request of @benoit-cty. Findings were checked by reading the code and running tests locally (merged with current master where relevant), but please double-check before acting on them.

Verdict: ✅ Approve with nits

The race is real. The monitor scheduler can append to the old list between the list comprehension and the self._power_history = [] rebind, and that sample is lost. The lock is correct:

• It is held only for the O(1) swap and the append. _get_power_from_cpus(), including the Power Gadget subprocess, runs outside it.
• There is no nested locking, so no deadlock risk.
• The removed empty-list branch was indeed unreachable.

56 tests pass on this PR merged with master.

Nits:

1. The test only proves that monitor_power blocks on the lock. It does not show the actual fix: that a sample appended while total_power() is running is kept for the next window. A test that appends from a second thread during the swap and asserts the sample appears in the next total_power() would lock in the behaviour.
2. The PR description describes a different test (a list subclass) from the one in the diff; please update it.
3. The branch is behind master; please update it.

[davidberenstein1957]

Made the changes in 44ef635: merged master, added a test that a post-swap sample lands in the next window.

Not done: updating the description's test paragraph (my PR-edit was blocked; the diff's tests are the lock-blocking one plus the new next-window one, no list subclass).