Using std mutex will clash with Cafe OS primitives.
Any function that can block or resume a thread (OSJoinThread, OSSignalEvent, OSResumeThread, OSSleepTicks, OSLockMutex..) can yield the current fiber and start running other PPC threads.

Take this example:

// part of a HLE function
OSSleepTicks(ONE_SECOND);

Instead of blocking the host thread for one second, coreinit threading will instead suspend the host fiber (or ucontext in posix terms) assigned to the current PPC thread. Then the PPC scheduler picks the next PPC thread to run and continues doing work. Eventually after the sleep timeout occurs the scheduler will switch back and resume the fiber from within OSSleepTicks. From the code's perspective the 1 second delay happened, but the actual CPU emulation thread never actually slept. In multicore emulation it can even be a different host thread that returned from OSSleepTicks.

I hope this explanation makes sense. What currently happens is that you carry the std mutex into other PPC threads because you are calling OS functions which can context switch. It can easily lead to deadlocks or race conditions.

The solution is to use OSMutex over std::mutex in HLE code. OSMutex cannot be used outside of PPC contexts, so in that case you have to use std::mutex but need to make sure that you are not holding the lock while calling any OS* functions.