Synchronize clonable module stop (mixed wait condition)

[SAndreas]

We have identified that, if multiple clonable module instances are executed and a specific module (e.g. the first launched module) is stopped (no waiting) and afterward all open modules are stopped at once (incl. wait) the "stop module.vi" an error 1 is returning.

Steps to reproduce

1. Create a project and add a new clonable module
2. Create a tester VI and implement the code above 
3. Run the VI and see error 1 at second Stop Module.

What is happening in the Background

Situation 1 - "Stall Data Flow" = 0

1. "Stop Module.vi" 2 runs into "Wait on Stop Sync.vi" and synchronizes stop over rendezvous.
   The acquired rendezvous size is 3 (Module 1 which is at stopping, Module 2 and Stop Module)
2. Module 1 is waiting in "Safe to Destroy Refnums.vi"
3. Module 2 runs into "Close Module.vi"
   
   1. Last clone instance is fire at (1)
   2. Releasing the Semaphore (2) will wake up module 1 that it is now safe to destroy refnums now.
      Module 2 runs into "Wait on Stop Sync.vi" (3) and synchronizes over rendezvous.
   3. "Stop Module.vi" and Module 2 waiting for a third participation to join the rendezvous.
   4. Module executes case to destroy Master reference.... and executes "Wait on Stop Sync.vi" (3) with no synchronization as the boolean "Wait for Module to stop?" is on false.
   5. Module 1 executes "Destroy Sync Refnums.vi" (4) and is destroying the rendezvous.
   6. Module 2 and "Stop Module.vi" will be release from the waiting of the rendezvous as the reference is now invalid and returning error 1.

Situation 2 - "Stall Data Flow" = e.g. 2000ms

1. In compare to the situation 1 the first module is already removed here. The obtained rendezvous has the expected size of 2.
2. When module 2 enters rendezvous synchronization in "Wait on Stop Sync.vi" (3) the expected amount of participant is reached, and the execution can continue.
3. In most of our tests, this situation worked fine and did not create an error.
4. For some situation, we had the behavior that shutdown of the first module seems to be faster as the wake-up from rendezvous of the second module. The module main of module 2 opened and showed error 1. Module 1 seems to destroy the references to early. 

Situation 3 - First Module will be stopped with last "Stop Module.vi" call

The shutdown of a module is for this scenario delayed (add a wait 1000ms to exit case of the module)

1. Stop Module 2 waits for 11 rendezvous participations. (10 module and itself)
2. One of the previously closed module will destroy the synchronization events and makes the rendezvous reference invalid. => Error 1 at "Stop Module.vi"

Potential Fix

Spoiler

The following screenshots are showing an extension of the "Stop Module.vi" and the "Close Module.vi".

The idea is to use a single element queue (SEQ) containing a map of sets. The key of the map refers to a "Stop Module.vi" which waits for stopping all module at the time when the "Stop Module.vi" is executed. The Set contains all Module ID's which should be stopped. Each module checks in its close condition if the SEQ is existing. If so, the module ID will be removed from the sets which containing the module ID. An empty set refers to all required modules have stopped and a notifier which is used for synchronization will be fired.
Close Module.vi extention
Stop Module.vi extention With those extensions, all three described scenarios should be fixed. In addition, should it be possible to stop all module and launch in the background new ones, the stop and wait will wait until all those modules ID run at the stop execution are finished.
I added the project which the extensions and tests to the post.

Addition

I'm not sure, but I think that with the described change, destroy of the Module's Semaphore (1) should be done with the boolean condition of the First & Last Instance (2). (Red line)

Please let me know if you need any additional information and details.

[Olivier-JOURDAN]

HI @SAndreas,

Thanks for reporting this bug.

It should be fixed in DQMH 7.0.

[Olivier-JOURDAN]

The DQMH version targeted is not known so far. DQMH7.1 🤞