Thiago Macieira wrote: > You do lose a bit in performance if you call QMutex::lock() on a QBasicMutex: > it makes an out-of-line call, instead of inlining the test-and-set. If not too > hard, call .lock() and .unlock() directly.
Should be the case for derefEngine() and prepareEngine_helper() . Something fishy happens with macx-clang (even 5.0.1) when I put the QBasicMutex into the EngineCache class, and pass &globalEngineCache()->m_mutex to QMutexLocker. I can get a bad_alloc exception when the locker has gone out of scope, and it depends on what I do elsewhere if that happens or not. Doing something UB can cause such symptoms, but I also get a crash (in QBasicMutex::lockInternal()) when I do globalEngineCache->m_mutex.lock(). We hang on to the global static QBasicMutex, and drop the use of QMutexLocker. Or the performance loss going to QMutex is small compared to the QCache operations we could go the cleaner and (possibly) safer route and use a QMutex class variable. R. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
