On terça-feira, 30 de janeiro de 2018 14:35:08 PST René J. V. Bertin wrote:
> 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.
Are you making modifications on top of Qt 5.9? I added a constexpr default
constructor to QBasicMutex in 5.10, but before that it depended on the zero
initialisation being performed beforehand. And that doesn't happen if you
create it on the stack or as a member, unless you explicitly add {}
afterwards.
In any case, don't make it a member. File-level static QBasicMutex is fine,
that's what it exists for.
> Doing something UB can cause such symptoms, but I also get a crash (in
> QBasicMutex::lockInternal()) when I do globalEngineCache->m_mutex.lock().
You have the symptom of QBasicMutex containing garbage. It is thinking the
mutex is locked.
> 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.
QMutex as a member variable in the class is fine too. Just don't make it
static.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
