Fix a data race in PersistentSymbolTable::filteredDeclarations() API [Follow-up from "Refactor ItemRepository mutex handling"]
The following discussion from !328 (merged) should be addressed:
-
@igorkushnir started a discussion: (+8 comments) The other data structures are still protected via the global duchain mutex.
In all functions but
filteredDeclarations()
DUChain is write-locked. Here it is only read-locked while bothm_importsCache
andm_declarationsCache
are modified. Therefore, this commit may introduce a data race when this function is concurrently called from multiple threads.Maybe we need to add another mutex to protect the caches? If so, do we still need to ensure DUChain is locked? Alternatively, could we replace
ENSURE_CHAIN_READ_LOCKED
withENSURE_CHAIN_WRITE_LOCKED
at the top of this function?
From !328 (comment 452016):
If I understand correctly, the returned
FilteredDeclarationIterator
references the caches. Seeing that the caches rely on a separate mutex, the duchain lock is not sufficient. Using the returned iterator while another thread callsPersistentSymbolTable::filteredDeclarations()
constitutes a data race. But if this data race was present even before the changes here, maybe we can merge this as is.