hardcoresushi/libcryfs
1
0
Fork 0
Code Issues Pull Requests Releases Activity

Keep resource destructor in ParallelAccessStore under mutex

Browse Source
This commit is contained in:
Sebastian Messmer 2016-07-14 15:10:52 +02:00
parent 3f04a7411c
commit 91bf6c3647
1 changed files with 6 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/parallelaccessstore/ParallelAccessStore.h
View File

@ -176,7 +176,9 @@ void ParallelAccessStore<Resource, ResourceRef, Key>::remove(const Key &key, cpp
cpputils::destruct(std::move(resource));
//Wait for last resource user to release it
auto resourceToRemove = _waitForResourceToRemove(key, std::move(resourceToRemoveFuture));
auto resourceToRemove = resourceToRemoveFuture.get();
std::lock_guard<std::mutex> lock(_mutex); // TODO Just added this as a precaution on a whim, but I seriously need to rethink locking here.
_resourcesToRemove.erase(key); //TODO Is this erase causing a race condition?
_baseStore->removeFromBaseStore(std::move(resourceToRemove));
}
@ -188,23 +190,15 @@ std::future<cpputils::unique_ref<Resource>> ParallelAccessStore<Resource, Resour
return insertResult.first->second.get_future();
};
template<class Resource, class ResourceRef, class Key>
cpputils::unique_ref<Resource> ParallelAccessStore<Resource, ResourceRef, Key>::_waitForResourceToRemove(const Key &key, std::future<cpputils::unique_ref<Resource>> resourceToRemoveFuture) {
auto resourceToRemove = resourceToRemoveFuture.get();
std::lock_guard<std::mutex> lock(_mutex); // TODO Just added this as a precaution on a whim, but I seriously need to rethink locking here.
_resourcesToRemove.erase(key); //TODO Is this erase causing a race condition?
return resourceToRemove;
};
template<class Resource, class ResourceRef, class Key>
void ParallelAccessStore<Resource, ResourceRef, Key>::remove(const Key &key) {
auto found = _openResources.find(key);
if (found != _openResources.end()) {
auto resourceToRemoveFuture = _resourceToRemoveFuture(key);
//Wait for last resource user to release it
auto resourceToRemove = _waitForResourceToRemove(key, std::move(resourceToRemoveFuture));
auto resourceToRemove = resourceToRemoveFuture.get();
std::lock_guard<std::mutex> lock(_mutex); // TODO Just added this as a precaution on a whim, but I seriously need to rethink locking here.
_resourcesToRemove.erase(key); //TODO Is this erase causing a race condition?
_baseStore->removeFromBaseStore(std::move(resourceToRemove));
} else {
_baseStore->removeFromBaseStore(key);