Design study: OpenMP-style teams with Rayon-style flexibility on threadteam's own workers (theory only) #22

Maintainer direction (2026-10-30): 「threadteamを独自スレッドで拡張していくとしよう．OpenMPの機能をメインにするが，Rayonの柔軟性も取り込めないか？理論的に検討させよう」. Addendum, same day: 「threadteamはOpenMP的にして，work stealingはRayonにますという手もあるね．例えば，tenferroのCPUEngineが両方のプールを持ってもいいわけだし．」

This is a theoretical study only, with no implementation. The deliverable is the design note docs/design/hybrid-scheduling.md, in a PR against develop.

The question: the main axis is OpenMP-style. That means:

• concurrent teams;
• barriers;
• stable thread numbers for static partitioning;
• places and pinning;
• wait policies;
• sub-teams.

How can Rayon-style flexibility (work stealing, join/scope, composability) live on the same workers? This is compared against the two-pool alternative, where an engine owns both a threadteam pool and a Rayon pool.

The note covers:

1. coexistence on one set of workers;
2. prior work, with primary sources (Cilk/OpenCilk bounds and child vs continuation stealing, TBB arenas, libomp tasks, BOLT, OpenMP 6.0 free-agent threads and taskgraph, Kokkos, HPX, Taskflow, Lace, NUMA-hierarchical stealing, reducers);
3. stealing at a barrier: safety conditions and latency bounds;
4. budget conservation with stealing, sub-teams from the reserve, nested teams inside tasks;
5. dependent tasks (depend, taskgraph replay, priority);
6. determinism boundaries in the API;
7. the Rust API shape and Rayon interop;
8. invariants with proof sketches, properties to check with TLA+, the staging order and the kernels and measurements that would justify each stage;
9. the two-pool alternative: oversubscription and idle CPU use, nested budget loss, placement, the ownership rule, tensor4all-rs Parallelism::Pool, the OpenMP+TBB precedent, a comparison table and the deciding measurements.

Method: pi-council (plan mode, several models including GPT-family).

Refs #16, tensor4all-meta docs/design/threading-substrate.md.