On Friday, 23 August 2019 14:51:36 CEST Mutz, Marc via Development wrote: > On 2019-08-23 14:31, Allan Sandfeld Jensen wrote: > [...] > > > condition_variable_any::_M_mutex > > I didn't say _any :) > > > The std::conditional_variable has the same problem QWaitCondition has. > > I don't think so: > > > https://code.woboq.org/gcc/libstdc++-v3/include/std/condition_variable.html# > 166 > > takes the mutex from the lock. > For waiting but not waking. I did note the libstdc++ non-any implementation doesn't lock for notifying, but it remains a fundamental requirement that you need to lock to modify the waiting queue, so I looked deeper:
So yeah, okay glibc does it, see https://code.woboq.org/userspace/glibc/nptl/ pthread_cond_signal.c.html#47 and https://code.woboq.org/userspace/glibc/nptl/ pthread_cond_common.c.html#254 It is just inherent to this kind of design that an extra lock is necessary. So std::conditional_variable_any and QWaitCondition has two extras, where the std::conditional_variable only has one extra mutex overhead. Oh well. Conditions are not exactly the most efficient of multi-threading primitives in any case. 'Allan _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
