I have found that, in some occasions, mutexing an object_free causes a deadlock. Here's an extremely stripped-out example:
Shortly after I turn on the toggle, Max hangs. In thread 1, it get stuck inside object_free (in what looks to me like a call to critical_enter, but my assembler skills are too limited for being sure); in thread 6, I am stuck inside systhread_mutex_lock.
The doc clearly states not to lock outlet calls, and I can easily see why. I don't really grasp what's happening here, though.
Of course, in this stripped-down scenario the solution is straightforward - assigning x->p_aa to a local variable, and freeing it after unlocking the mutex. I am aware that this would also be a better design choice, to keep the locked code as small as possible.
Unfortunately, the problem popped out in a far more complex situation, in which avoiding to free anything inside the mutex would be hell.
What I'd like to know is:
- Why exactly this problem arises? Is it something related Max's global critical region? Perhaps, my systhread_mutex_lock call happens inside the global critical region?
- The problem doesn't seem to arise in every possible situation. Is it just by chance, or are there specific conditions triggering it?
- Would the situation improve if I manage my object's lifecycle with object_retain() and object_release(), as Joshua was suggesting me some days ago?
- Do I have an easy solution????
Thank you very much, as always