Hello,
I am running into a race condition when triggering multiple simultaneous automations from SRM booking manager custom events.
When a booking event fires it launches a script which then triggers a subscript that should lockout the dummies defined in the subscript. See below:
var subscript = engine.PrepareSubScript("MakeSplice");
subscript.SelectDummy("Source", source);
subscript.SelectDummy("Destination", destination);
subscript.LockElements = true;
subscript.WaitWhenLocked = true;
subscript.Synchronous = true;
subscript.StartScript();
If I trigger the multiple scripts manually I can see the first subscript locks the element, and the following subscripts wait for the first to unlock before proceeding, as I would expect. However, when the booking manager triggers the same scripts they do not queue properly. Although the first script to fire locks the element, it does not prevent competing scripts from making changes on the same element.
Is this expected behaviour or a bug? Is there some other way I can enforce the element lock when triggering scripts from the booking manager?
Hi Richard,
Instead of relying on the LockElements subscript property, I suggest using a named Mutex object to enforce non-concurrent script execution. To do so, define a static object as a field of the Script Class:
private static Mutex mutex= new Mutex(false, "MyScriptMutexObject");
Now, in the Run method (or at any other place in code that you want to ensure won't be concurrently executed), use a try/finally statement to acquire and release the Mutex object:
try {
mutex.WaitOne();
// Non-concurrent code here
}
finally {
mutex.ReleaseMutex();
}
Be aware that using WaitOne with no arguments will block the thread indefinitely, which could lead to a cascade of failed script executions in case one of them acquired the mutex but couldn't complete it during the script's timeout. You may want to use the version with a timeout ( mute.WaitOne(TimeSpan.FromSeconds(30), false)) so that subsequent executions will have the opportunity to gracefully complete, logging the detected lock condition.
That's a great solution. Worked perfectly, Thank you!