[bipinkrish]

What

Persistent workers repeatedly reacquire the shared manager mutex while idle. On the Windows host reported in #13026, one worker can monopolize that mutex and leave the other persistent workers blocked.

Keep persistent workers spinning on workEpoch outside the mutex until dispatch, shutdown, or a persistent-count change advances the epoch. Preserve the bounded timer-spin path and the existing sleep and wake-token accounting.

The overlap warning for #10249 was checked manually: its JobManager hunk changes Sequence::SubmitCompute, while this PR changes WorkerEntry; neither depends on the other.

Tested

• Previously reported on the original PR head: Linux Release JobManager tests passed in three full rounds, once pinned to two CPUs, and worker_count passed ten direct runs. Hosted Windows CI passed.
• The original report's idle Windows starvation was not reproduced on Linux. A rerun on the affected Windows host remains useful.
• Review validation on Ubuntu 24.04.4 x86-64, GCC 13, Release, after merging main at e67cc81869: rebuilt the five JobManager test targets; ctest --test-dir build -R '^guest_job_manager_' --output-on-failure passed 29/29. The tests ran outside the Codex sandbox because its syscall filter denies the checked guest-memory writes.
• git diff --check and convention/template checks passed against current upstream main. The required --base origin/main check also passed with eight pre-existing debt-length warnings from the fork's older base.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: Fixes libSceJobManager: persistent workers starve on the shared lock, so guest_job_manager_worker_count fails on an idle host #13026
• Unblocks: none
• GPUs tested: n/a (CPU worker scheduling only; no AGC, shader recompiler or VideoOut changes)
• AI-assisted: yes

[MarcZX10]

Reviewed — looks good

At head f0c452699298fa3c2882e820cec591e463b65c1c against base 73f4f7e06e4f210a8c6570e335fd654dc0a86134, the persistent-worker idle loop now waits on the atomic epoch without holding the manager lock; dispatch, shutdown, and persistent-count changes advance that epoch so the worker can reacquire the lock and recheck state (idle loop, dispatch wake, shutdown and persistent-count updates). git diff --check, conventions/template validation, and the current-base merge preview passed; hosted Windows passed. The Linux test and Vulkan results are author-reported, Linux CI was skipped, and I did not build or run tests locally.

[bipinkrish]

Sorry miss-click

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 10249	core/libs/prx/libSceJobManager/Export.cpp

[adriadam10]

Checked that every path that makes work runnable (runQueues.Push via WakeWorkers, StopManager, setPersistentThreadCount) bumps workEpoch, so persistent workers spinning outside the lock cannot miss a dispatch, shutdown or count change; the timed-spin path is unchanged. Windows and conventions green; merged.