From 7074dab2da48fcb4eb46ec4b22eed40c6cec4b1b Mon Sep 17 00:00:00 2001 From: Weiyi Wang Date: Fri, 8 Feb 2019 10:43:06 -0500 Subject: [PATCH] Memory: don't lock hle mutex in memory read/write 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. --- src/core/memory.cpp | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/core/memory.cpp b/src/core/memory.cpp index 7080b30dc..4c009bbe3 100644 --- a/src/core/memory.cpp +++ b/src/core/memory.cpp @@ -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 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 lock(HLE::g_hle_lock); - PageType type = impl->current_page_table->attributes[vaddr >> PAGE_BITS]; switch (type) { case PageType::Unmapped: