if u r talking about std::mutex, then try this:

• remove all your locks/unlocks and replace with:

 std::mutex your_mutex;
 
 void render()
 {
 	std::lock_guard<std::mutex> guard(your_mutex); 
 	... your render code ...
 }
 // do the same in the other function

have fun ?

jakovo said:
but on others … it gets stuck waiting

How do you test that? I came over some interesting cases where the OS behavior changes in between debug and release mode. It was possible to lock a mutex on the same thread in debug mode (to lock the thread out itself) but in release mode this passed through and the code didn't work as expected and testet in debug.

In general, the OS sets threads asleep when they run into an already locked mutex and assigns an event to them, which means that when the mutex gets unlocked, all events are fired and the threads awake trying to get the lock. However, the OS Scheduler prioritizes already running threads over those that were at sleep for a while. This ends into some milliseconds of delay from a lock released to a thread awaking and is totally unpredictable.

One scenario I can imagine in your case is that the OS is running the Render-Loop faster than any Event can get the lock and so it is missing that all the time. I don't know how you setup your Render-Loop and who is calling the Event function, maybe some code in Render causes Events to drop which will be a lockout. Or it is just the CRT which is somehow different or an Update that is installed or some Hardware-Tweaks. However, it gets really difficult to get into that without a good test-setup.

My suggestion, if you don't want to use the lock_guard, use the mutex and an additional signal which is set in any event call. So Render is doing it's thing and after you unlock everything, test the signal. If it is set, Render will automatically go to sleep for as long as Event is running

there's no definitive answer here, what u thought was a deadlock could have a been an Undefined Behaviour (UB) and we could talk about UBs for the rest of our lives;

it's not because the lock_guard workaround appears to work that u should think u have solved the issue;

the removal of lock/unlock calls and the intro of lock_guard might have shifted the real problem elsewhere;

having said all this, there are truths which are commonly known such as locking 2 or more mutexes in opposite orders (by multiple threads) causes a deadlock;

but there are many other realities which even the C++ committee define as Undefined Behaviours (UB), for example, when the same thread tries to lock the same mutex (that's also a UB and not a deadlock), and this could be what happened in your case or maybe not (here we go);

it gets even more interesting when exceptions are turned off;

the reason I suggested to use lock_guard is because even though u can call lock/unlock on a std::mutex it is not recommended by C++ code of practice;

std::mutex should not be used directly -as u did-, always try to use one of the mutex management offerings namely: lock_guard, shared_lock, scoped_lock, unique_lock… they are all different and have a specific meaning, but these are all designed to offer “better” mutex management ownership to the calling thread and exclusivity (i'm not 100% sure about all the mechanics underneath this but i have seen enough to believe that these RAII locks are better to use then the mutexes themselves);

so stick to these and things should be a bit better 4 u ?

that's it… all the best ?

When exceptions are thrown, you should usually be warned by the CRT and the thread will break even if you turned them off so this should not be kind of an issue. I write C++ without any exceptions in general and always saw when something broke, regardless if it was debug or release code so trust the CRT!

Btw. are you sure you want to lock the entire Render loop? What are you doing that it isn't possible to fine grained lock specific critical resources you are using or could you even use atomic operations for some of them (like incrementing a variable, changing a pointer etc. )?

To be honest, I never ever needed a full lock in my game code so far when a simple spin locking was enougth or read/write locking in a lot of cases when resources where changed rarely but read often

template<typename T> force_inline void lock(volatile T* flag) 
{ 
    while (Interlocked::Exchange(flag, 1)) 
        while (*flag) 
        { }
}
template<typename T> force_inline void unlock(volatile T* flag)
{
    Interlocked::Exchange(flag, 0);
}

jakovo said:
What I meant is that if you manually lock the mutex, and then some exception is thrown, the thread will break and you won't be able to unlock the mutex, and so every other thread waiting for it will be stalled for ever.

Sure but as I wrote above, the OS will prompt an exception dialog if you didn't ctahc anything and close the application (related to where the exception was thrown) so you won't anyway be able to further execute any code that may stall forever. Unless you built an exception handle into your code that will catch and raise those signals on a per-thread level. In this case you might be able to rescue your application but then yes, sure you will be stalling at some point.

jakovo said:
Well, In the render loop I'm iterating over my renderables

This sounds like the classic “an event handler is removing itself from the list of event handlers while they are processed” scenario. As it “may” but must not happen, go for the ReadWriteLock approach and you'll not just saving performance but also only work on those items if needed and not all the time and I guess it is ok for your events to spin-wait some time. I use those locks together with simple exclusive spin-locks all the time (battle.proof might be no the right workd but somehow) and they work well for me. Another approach I tried once I wrote my event handler to solve the issue above was to maintain two pointers to such a list at a time. One was used to add/remove handlers while the other was for processing. I simply copied one list into another when the processing was called again. I don't know if this is fast enougth for a render loop but it worked well in my event system