Commit 2032a721 authored by Milian Wolff's avatar Milian Wolff
Browse files

Add missing mutex locking for some ItemRepository functions

These are all not thread safe and thus must lock the mutex or
risk undefined behavior.

Igor Kushnir writes:
> ItemRepository::close() was called from:
>
> 1. ~ItemRepository() and ItemRepository::open() - no need for a lock;
> 2. ItemRepositoryRegistry::unRegisterRepository() - no need for a lock because unRegisterRepository() is called only from within ~ItemRepository(). But there seems to be an inefficiency here: close() is called from unRegisterRepository() and then immediately from ~ItemRepository() again. Should perhaps this call be removed from unRegisterRepository()?
> 3. from ItemRepositoryRegistryPrivate::close(), which in turn is called from ~ItemRepositoryRegistry(). Here the missing mutex lock might have been a bug.

Then there was `ItemRepositoryRegistry::printAllStatistics` which
didn't lock the repository mutex when printing statistics.
parent ebf09553
......@@ -1593,6 +1593,7 @@ public:
Statistics statistics() const
{
QMutexLocker lock(m_mutex);
Q_ASSERT(m_currentBucket < m_buckets.size());
Statistics ret;
uint loadedBuckets = 0;
......@@ -2079,6 +2080,7 @@ private:
///@warning by default, this does not store the current state to disk.
void close(bool doStore = false) override
{
QMutexLocker lock(m_mutex);
if (doStore)
store();
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment