So what I not understand about this design is how one uses it. In the classic condvar application one waits atomically with the lock because otherwise the other thread may deliver the signal before the wait happens, leading to a deadlock.<p>Here it seems there is no atomicity. How does this get used?
BeOS, which is the foundation for most of this work, is from the 1990s. But in the 1990s C++ didn't yet have a clearly defined Memory Model for the purposes of concurrent algorithms and BeOS doesn't try to come up with one.<p>In the subsequent 25+ years, C++ developed a Memory Model which distinguishes ordering for these atomic operations. Because BeOS pre-dates that, it doesn't document an ordering, let alone provide a mechanism to pick one. Unfortunately different concurrent algorithms have different ordering requirements, if what you're given is looser the algorithms may malfunction, if it's stricter the performance may be hampered.<p>I reckon that before trying to claim you've innovated here it might be a good sense check to compare baseline. What exactly are the Haiku atomic operations, in terms of the C++ 11 Memory Model ? If you were Linux (or to some extent Windows) you could trail blaze here, because you're innovating <i>before</i> 2011, you're inventing the model - but this is 2023, so Haiku is off in the jungle on its own and everybody else has a map now, figure out where you are on that map first.