Answers to this question give great explanation about the rationale behind using locks instead of bare mutexes for condition variables in C++11 (or Boost) - C++11: why does std::condition_variable use std::unique_lock?
I'm designing an RTOS for deeply embedded targets, which - mainly because of memory constraints (these microcontrollers usually have ROM in the range 128kB-1MB and RAM 16-128kB) - is meant to be used without exceptions*. That's why instead of throwing exceptions in mutex functions (or any other functions) I return error codes, just like POSIX pthread does. In such design implementing sth similar to unique_lock from C++11 is still simple, but I feel that it is a bit wrong... When you have exceptions, failure to lock the mutex with unique_lock cannot be "missed", because an exception will be thrown. When you don't have exceptions you can either call abort() on a failure or keep last error code in the lock and provide an accessor to get it (there's no way to nicely and easily return error from constructor) - I feel that both of these solutions are "wrong" and I cannot think about anything better... That's why for now my implementation of condition variables uses bare mutexes (like POSIX pthread functions), and no equivalent of unique_lock is implemented.
On the other hand I don't rule out a use-case when someone actually DOES use exceptions, but these cases will be an "exception" to the rule...
My problem is that I cannot think about a solution that would be good for both scenarios (with or without exceptions).
So does it make sense to implement equivalent of unique_lock and use that with condition variable instead of bare mutexes, when the code is written with error codes instead of exceptions? Is there any non-ugly solution for creating an unique_lock that would use mutexes which return error codes instead of throwing? I really feel that calling abort() (or asserting) is pretty wrong, as it gives the user no chance to deal with the error... Returning error codes from an object using RAII semantics is also pretty wrong. It could work when using a factory method (pulling in dynamic allocation or using sth like std::optional), but is this feature (unique_lock for condition variable) worth all the trouble in case of plain and simple error codes?
* - despite popular catch-phrase that "you don't pay for what you don't use" it is actually not possible to completely disable exceptions in GCC easily. If you use -fno-exceptions flag, you disable exceptions for YOUR code, but the code for handling exceptions in the library is still there, so it's enough to call new, create a string or maybe a vector and the code for handling exceptions is included anyway. This may be no difference for a desktop environment, but for deeply embedded these few dozen of kilobytes of code for a feature that you will not use (can be limited by overriding verbose_terminate_handler(), but it still leaves a lot) make a difference. To completely disable exceptions I recompile whole toolchain for ARM microcontrollers passing -fno-exceptions to the process of compiling the standard library itself - only then this feature is removed.