mirror of
https://github.com/yuzu-emu/yuzu.git
synced 2024-07-04 23:31:19 +01:00
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.
This commit is contained in:
parent
3c39b39bbc
commit
5159f4eee8
1 changed files with 0 additions and 6 deletions
|
@ -171,9 +171,6 @@ T Read(const VAddr vaddr) {
|
||||||
return value;
|
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 = current_page_table->attributes[vaddr >> PAGE_BITS];
|
PageType type = current_page_table->attributes[vaddr >> PAGE_BITS];
|
||||||
switch (type) {
|
switch (type) {
|
||||||
case PageType::Unmapped:
|
case PageType::Unmapped:
|
||||||
|
@ -204,9 +201,6 @@ void Write(const VAddr vaddr, const T data) {
|
||||||
return;
|
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 = current_page_table->attributes[vaddr >> PAGE_BITS];
|
PageType type = current_page_table->attributes[vaddr >> PAGE_BITS];
|
||||||
switch (type) {
|
switch (type) {
|
||||||
case PageType::Unmapped:
|
case PageType::Unmapped:
|
||||||
|
|
Loading…
Reference in a new issue