DQMH Event Request VIs could they be changed from 'Non-reentrant' to 'Preallocated Clone Reetrancy' ?

[Vincent90]

Hello !

We have an event request VI with a wait for reply needed (included into an helper loop) from case to case called into 15 cloned modules.

We feel like there is a bottleneck into that request which is bringing jitter into other clones.

I wonder if it could be possible to change this request event VI into Preallocated Clone Reetrancy ?

Does it fit DQMH usage rules ? I couldn't find any post regarding this matter.

Best Regards,

Vincent

[Darren]

I see no issue with changing a Request and Wait for Reply VI from shared clone to preallocated clone reentrancy. I'm surprised that setting alone though is fixing a jitter issue. Unless you're constantly starting/stopping cloneable module instances I would expect that once the clone instances of the Request VI are created there wouldn't be much happening with the clone pool.

[Vincent90]

Hello Darren,

Thanks answering this topic.

The question is about to change the default VI execution setting "Non-reentrant" to "Preallocated Clone".

Issue is the following.

Module is running an helper loop with an Event Request which is asking to "do smth" with "Wait For Reply" set to true into MHL Main loop.

Module is cloned 15 times.

My worry is about this ; if the event request VI is set to Non-reetrant. This wait for reply might include jitter to others modules cloned because of Wait For Reply" locking VI execution until "Do smth" ended.

The solution then will be to set this Event Request VI to "Preallocated Clone" so each clone could send this Request in parallel.

You already answered it, that's could fit to DQMH framework rules, so i am going to try it.

Thank you for your time.

Vincent

[joerg.hampel · Accepted solution]

In DQMH 6.1, the default setting for a "Request and wait for reply" VI of a cloneable module should be "Shared clone reentrant execution", as shown here:

I can totally see how you would experience jitter if your request VI is actually set to non-reentrant execution. Please use the DQMH Module Validator to check if any VIs in your module are set to non-reentrant and fix those. 

I'd be surprised if you still saw jitter after making these fixes, and - same as Darren - I'd be also surprised if switching from "Shared clone reentrant" to "Preallocated clone reentrant" made any noticeable difference.