I have to wonder what's so different in your environment as to break this

Simple.

threads::shared cond_* variables and associated APIs, map directly to Pthreads condition variables; thus, they have a fair chance of working on platforms that have native pthreads.

Conversely, Windows has no direct analogy to pthreads condition variables, hence they have to be emulated using those synchronisation primitives that Windows does provide. That emulation is done crudely, and badly and has to my knowledge never worked correctly. Hence why I have avoided them like the plague.

For the most part, if used sensibly -- which means not relying on the (long identified as broken) edge-trigger semantics that underly cond_wait() -- threads::shared's emulated cond_vars can be used on Windows; but doing so successfully requires an understanding of their inherent limitations (which exist everywhere, but are exacerbated by the crude emulation on Windows), and that requires that the designer has actually written and debugged real-life code doing real work; not just thrown together a few do-nothing, trivial examples for the purposes of establishing cred.

The sad part is, Window's native synchronisation primatives are extremely rich and powerful; and do not suffer the Achilles heel of Pthread's one and only synchronisation mechanism -- namely, spurious triggers.

For Far more than You Ever Want To Know about the problems of trying to accurately emulate Pthreads cond_vars (broken) semantics on windows see: 3. Implementing Condition Variables on Win32.