Forward-aggregator header for all jh::*_pools. More...

#include "jh/concurrent/observe_pool.h"
#include "jh/concurrent/resource_pool.h"

Detailed Description

Forward-aggregator header for all jh::*_pools.

This header provides the canonical include entry for jh::*_pool<...>s — a high-level, user facing around jh::conc::*_pool<...> pool bases.

#include <jh/pool>

Internally, it includes the user facing pool interfaces from jh/concurrent/*.h and exposes them collectively.

Platform Semantics
All pool implementations in <jh/pool> are designed to be data-race-free at the algorithmic level.

All shared mutable state is protected by explicit locks.
Reference counters and liveness indicators use atomics.
No intentional lock-free data races exist.

The concurrency design assumes a strong acquire/release synchronization contract between:

lock/unlock operations, and
C++ atomic operations.

On POSIX platforms (Linux / Darwin), this assumption is satisfied by mature implementations built upon:

pthread_rwlock
futex-based primitives
well-integrated compiler/runtime memory semantics (GCC / Clang)

Under these environments, the synchronization graph forms a complete happens-before closure in practice. The pools are considered engineering-grade well-formed and have demonstrated stable high-concurrency behavior.
The design intentionally leverages these stronger implementation semantics. It does not restrict itself to the minimal guarantees of the ISO C++ abstract machine, as doing so would significantly reduce expressiveness or introduce prohibitive synchronization overhead.

Windows Support
Windows is treated as a secondary platform.
While the code remains data-race-free at the C++ level, certain combinations of:

MinGW (libstdc++)
Windows runtime libraries (MSVCRT / UCRT)
SRWLock-based synchronization paths

have been observed under extreme concurrency to exhibit rare visibility gaps or ordering jitter.

These effects appear to stem from subtle differences in how C++ atomic semantics interact with Windows runtime synchronization primitives. In particular, control blocks associated with weak_ptr, shared_ptr, or atomic reference counters may not always participate in a fully closed visibility chain under high parallel pressure.
Additional fences are introduced on Windows builds to strengthen ordering, but they cannot eliminate all anomalies when interacting with certain runtime configurations.
Therefore:

Full concurrency robustness is guaranteed only on POSIX.
Windows usage is recommended for single-threaded or low-contention workloads.

The primary validation and release target of this toolkit remains POSIX systems (Linux + GCC/Clang, Darwin + Clang).