Howard Hinnant wrote:
I'm not concerned about running out of memory. I'm concerned about generating more L1 cache misses.
A valid point, especially if sizeof(pthread_cond_t) is 4 or 8.
We have several opposing use cases we need to satisfy with std::condition:
1. Minimum size - performance overhead. 2. The freedom to dynamically associate mutexes with condition variables. 3. The ability to apply run time check consistency concerning the associated mutex. 4. The ability to wait on general mutex / lock types.
I'd suggest a different approach in meeting these needs. Remove the "shall throw on error" requirement and replace it with a Requires clause that says that lk.mutex() must be equal to the address of the constructor argument, if supplied. Now: 1. Enabled by compiling against the release runtime. 1a. Minimum size, almost no performance overhead: enabled by compiling against the "checked release" runtime that does not increase sizeof(std::condition) and as a result may miss some errors. 2. Enabled by not passing a mutex in the constructor. 3. Enabled by passing a mutex in the constructor and compiling against the debug runtime. 4. As before. Switching between 1/1a/3 requires no source changes. Switching between 1 and 1a requires no recompilation. If binary compatibility between 1 and 3 is desired, it could be possible to engineer the debug runtime to meet this case as well, even though it would be less convenient and possibly carry more overhead than just storing a mutex* in the condition.