The-Homebrew-Cloud/Lime3DS
2
0
Fork 0
mirror of https://github.com/Lime3DS/Lime3DS.git synced 2024-11-24 02:29:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Memory: don't lock hle mutex in memory read/write

Browse Source 
The comment already invalidates itself: neither MMIO nor rasterizer cache belongsHLE kernel state. This mutex has a too large scope if MMIO or cache is included, which is prone to dead lock when multiple thread acquires these resource at the same time. If necessary, each MMIO component or rasterizer should have their own lock.
This commit is contained in:
Weiyi Wang 2019-02-08 10:43:06 -05:00
parent bad2e084e3
commit 7074dab2da
1 changed files with 0 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/core/memory.cpp
View File

@ -176,9 +176,6 @@ T MemorySystem::Read(const VAddr vaddr) {
return value;
}
// The memory access might do an MMIO or cached access, so we have to lock the HLE kernel state
std::lock_guard<std::recursive_mutex> lock(HLE::g_hle_lock);
PageType type = impl->current_page_table->attributes[vaddr >> PAGE_BITS];
switch (type) {
case PageType::Unmapped:
@ -213,9 +210,6 @@ void MemorySystem::Write(const VAddr vaddr, const T data) {
return;
}
// The memory access might do an MMIO or cached access, so we have to lock the HLE kernel state
std::lock_guard<std::recursive_mutex> lock(HLE::g_hle_lock);
PageType type = impl->current_page_table->attributes[vaddr >> PAGE_BITS];
switch (type) {
case PageType::Unmapped: