Is this necessary? The variable is only used in getDataDirs(). Some of the others are similar.

Can these be next to the variable-containing-function they protect?

Does it make sense for this to protect both cachedSearchPaths() and cachedCustomIncludes()? They don't seem particularly related.

This doesn't look thread-safe (in either the old or modified version); nothing locks the value while it's being written to.

ditto

ditto

ditto

ditto...

I don't believe this is truly safe. It prevents multiple threads writing simultaneously, but other threads may read while the write takes place, which isn't permitted.

Either the mutex should cover the whole thing, or it might be more performant to use a QReadWriteLock?

Of course, since there was no locking at all before and nothing blew up, this is probably a statistical irrelevance...

As above.

why is this locking the cache mutex? shouldn't / couldn't you simply lock the duchain here instead?

instead of using the mutex for this, initialize this static directly (that is guaranteed to be threadsafe with c++11):

static const  auto correctionFileDirs = QStandardPaths::locateAll(...);

dito

this is still not thread safe due to calls like this. you should probably ensure this is only being called from the main thread. once you have done that, afaik you can remove the cacheMutex as it won't be needed anymore