ok i think i understand what it happens. The emulator has a state : normally it is RUNNING when interpreting a PSP game. Some events like Audio, Vsync, Clock may occur and try to set this state to an event state so the emulator thread is leaving the interpreter to handle the event. In a multi-core processor, each event has its time-critical thread running on one core whereas the emulator thread is running on another core. So a core tries to set a state to make the other core to suspend interpretation and handle event in the emulator thread. I feared an event state might be set when the emulator was already set to another event set (a vsync event occuring when the emulator state is set to an audio event state), so in 5.1.0, i changed into something like that :
it didn't fix the freeze issue but i left this code. However i never realized that code might not work properly for a mono-core as those threads will be executed in a sequential order and might create some slowness or deadlocks indeed.
Code:
step 1:
lock mutex;
if emulator state is RUNNING,
set emulator state to event and unlock mutex;
else
unlock mutex and repeat step 1;