Lockup of two SM instances about finite_machine HOT 4 CLOSED

Thank you for reporting this, I will definitely take a look. I didn't intend this to be a feature, if anything, I wanted to ensure that instances of FM are threadsafe but independent of each other. You should be able to create a system of state machines that cooperate to solve a task, this deadlock is a bug, not a feature. Let's fix it!

from finite_machine.

@domokos Thank you for the code, it was super helpful in zeroing in on the problem! I have added a simpler version of your code as a integration test case to keep this bug at bay for the future.

Turns out the issue was to do with how state machines trigger and emit callback events, more precisely, how threads acquire an exclusive lock to be able to issue and observe events. My thoery is that the mutex has become a global mutex for the whole state machine, meaning, once thread triggered the event it also got to have a lock for the observer to emit callbacks and hence locking up any other thread from responding to events from any callbacks. Hence I think triggering an event from a different thread helped to fix the issue as a new mutex was created and hence new lock could be acquired. Long story short, this should be fixed now as both observer and event triggering should have separate locks. I will let you know once released, all is in master if you want to checkout.

from finite_machine.

Released v0.11.2 that includes the fix, would you mind trying it out?

from finite_machine.

@peter-murach Thank you for resolving this so fast.

I installed version 0.11.2 and can confirm that this version does not have this bug any more. It works as expected.

This issue can be closed.

from finite_machine.