Restore SMP blocking priority boosts

[eedvardss]

An SMP thread that blocks on a mutex keeps its base priority instead of receiving the temporary boost described in the manual. When an equal-base thread is already runnable, explicitly yielding after releasing the mutex selects that later thread first. The same public-API probe selects the previously blocked thread first under unicore. The probe confirms that blocking occurred and uses an unowned mutex and a long quantum to isolate this behavior.

Restore boosting before SMP mutex, condition-variable, join and device-I/O waits enter their queues. Clear the boost on yield, including its single-runnable-thread path, and preserve unicore's existing sleep behavior. These helpers operate on the current running thread, avoiding the generic queue-repositioning paths. Unboosting recomputes the maximum inherited priority from owned mutexes with try-locks and balanced cleanup; the generated helper code uses direct F64 operations without allocation or heap checks while locks are held.

Related work and scope

The quantum counter also needs to be cleared at these boundaries. This prerequisite overlaps the quantum-accounting behavior already reported by @jannis793 in #1034, which deserves credit for that finding. A priority-only version of this fix passes the basic blocking-order probe but loses the renewed boost too early when the thread consumed part of its old quantum. The complete version restores the same three-tick duration as unicore. This submission seeks consideration only for the distinct missing blocking-priority behavior, not a second award for quantum accounting. I can adapt the change to the eventual form of #1034.

This does not incorporate #1022 or #1032, repair arbitrary concurrent priority setters, or complete all SMP inheritance/preemption TODOs. The original ordering probe uses explicit yield and no priority setter. Two regression fixtures initialize boost fields on inactive workers to isolate zero/custom boost transitions from the separate public-setter lock issue in #1022.

Validation

Tested on macOS arm64 at dcd677cd3e40860bdd27dfbdbf5e3ce46ab03813, with the compiler rebuilt from current Scheme sources, --enable-smp --enable-multiple-threaded-vms --enable-c-opt=-O1, and bounded child processes with explicit heap limits.

• Original public-API probe: unchanged unicore passes three times; unchanged SMP at p1 fails three times; the final SMP runtime passes.
• Checked-in regression: unchanged unicore passes and unchanged SMP fails 16 assertions. Final interpreted and native-compiled runs pass at p1, p2 and p4; the native unicore run also passes. Ordering cases deliberately pin workers to one processor.
• Regression cases cover yield/quantum expiry, immediate and timed waits, join and condition waits, the sleep exception, repeated and zero boost, empty owned queues, and inherited maxima across two populated queues in both orders.
• Separate Unix-only validation reads from a real /bin/cat process pipe after the reader has blocked: unicore and the final runtime pass; unchanged SMP fails. Final checks also pass with p2 and p4; the I/O worker remains pinned to one processor.
• A separate contention control distributes workers across every enabled processor, yields while holding mutexes, and checks exact protected totals: 2,000 / 4,000 / 8,000 operations at p1 / p2 / p4. Five additional runs each at p2 and p4 pass. This is bounded liveness evidence, not instrumentation of every retry branch.
• Of 75 selected existing thread-test runs (25 files at p1/p2/p4), 73 pass. thread_interrupt.scm raises the same inactive-thread error on unchanged SMP at p1. One p4 mutex_race_timeout.scm run times out after 60 seconds; its cause remains unresolved. Subsequent bounded p4 trials also observe segmentation faults on unchanged SMP (1/10) and the candidate (3/10). These results do not certify the complete SMP suite or establish that the timeout is unrelated.

Run the checked-in regression with a rebuilt runtime:

gsi -:p4,m512M tests/unit-tests/06-thread/thread_blocking_boost.scm

For consideration under #760 as one blocking-priority correction, subject to maintainer adoption and confirmation that an award remains available. The standing offer is EUR 100 per qualifying adopted fix. No award or payment agreement is assumed; payout details can be supplied privately if approved.