[PR #3179] [MERGED] video_core: use shared first mutex (reader priority shared mutex) to resolve deadlock #3288

New issue

Closed

opened 2026-02-27 22:03:08 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 22:03:08 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/shadps4-emu/shadPS4/pull/3179
Author: @LNDF
Created: 7/1/2025
Status: ✅ Merged
Merged: 7/2/2025
Merged by: @georgemoralis

Base: main ← Head: deadlock-fix

📝 Commits (1)

48f660f Use shared_first_mutex

📊 Changes

3 files changed (+49 additions, -1 deletions)

View changed files

📝 CMakeLists.txt (+1 -0)
➕ src/common/shared_first_mutex.h (+46 -0)
📝 src/video_core/renderer_vulkan/vk_rasterizer.h (+2 -1)

📄 Description

From the discord:

Just checked and the lock that I thought was exclusive was already a shared lock.
What is currently happening is:
thread a (gpucommand) locks the mapped_range mutex (shared lock)
thread b (the mapmemory thread) waits to lock the mapped_range mutex (exclusive lock)
thread c (the one invalidating memory) waits to lock the mapped_range mutex (shared lock)

The logic says to me that, if thread a and c have shared locks, they could both acquire the lock. But apparently, if thread b tries to acquire exclusive lock before thread c tries to acquire a shared lock, exclusive lock takes preference and all other shared locks need to wait untile thread b releases the lock (causing a deadlock in this instance). To solve that I will have to implement custom mutex that doesn't have this behaviour.

I can change the name of the mutex if you think is not descriptive enough

@StevenMiller123

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/shadps4-emu/shadPS4/pull/3179 **Author:** [@LNDF](https://github.com/LNDF) **Created:** 7/1/2025 **Status:** ✅ Merged **Merged:** 7/2/2025 **Merged by:** [@georgemoralis](https://github.com/georgemoralis) **Base:** `main` ← **Head:** `deadlock-fix` --- ### 📝 Commits (1) - [`48f660f`](https://github.com/shadps4-emu/shadPS4/commit/48f660fdd30ff8a100f8b60166bfec55e271f4de) Use shared_first_mutex ### 📊 Changes **3 files changed** (+49 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `CMakeLists.txt` (+1 -0) ➕ `src/common/shared_first_mutex.h` (+46 -0) 📝 `src/video_core/renderer_vulkan/vk_rasterizer.h` (+2 -1) </details> ### 📄 Description From the discord: > Just checked and the lock that I thought was exclusive was already a shared lock. > What is currently happening is: > thread a (gpucommand) locks the mapped_range mutex (shared lock) > thread b (the mapmemory thread) waits to lock the mapped_range mutex (exclusive lock) > thread c (the one invalidating memory) waits to lock the mapped_range mutex (shared lock) > > The logic says to me that, if thread a and c have shared locks, they could both acquire the lock. But apparently, if thread b tries to acquire exclusive lock before thread c tries to acquire a shared lock, exclusive lock takes preference and all other shared locks need to wait untile thread b releases the lock (causing a deadlock in this instance). To solve that I will have to implement custom mutex that doesn't have this behaviour. I can change the name of the mutex if you think is not descriptive enough @StevenMiller123 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>