DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Delacor_lib_QMH_enqueue Message(poly) not working as expected in prority case

Hi thanks for your super toolkit.

Today i want validate one case of use in your QMH toolkit. My case is to simply added fews messages queue with priority in front of the queue. But during my test, i encounted a strange result, the step aren't in expected order. After looking in Delacor_lib_QMH_enqueue Message(poly).Vi, i show than vi run as coded, but not as (for me) expected and logical. I think than when you want add few steps with priority you want add all steps in same order than in Message  array, but with your vi it's not the case. For exemple if you want add 4 Messages (1,2,3,4) with priority, you want obtein 1,2,3,4, but with your vi you obtein 1,4,3,2.

I send you a test vi to see that.

I have work arround and propose fews modifications for that vi.

1) I don't understand why you want creat array for priority (boolean array priority message). I dont show why mix priority and not priority are use case. And result order is complitely unpredical. I propose to modifiy array by juste one boolean, and in this case  all message array became priority (front) or not (back).

2) In case of the queue is empty, the priority has (for me) no sense,and i put all added Message array with no priority to respect order.

3) In case of the queue isn't empty, i invert all added Message array (and Message Datas array too) to respect order.

I send you one version of modified VI to see how. You must add it to your delacor QMH library to run it.

Eric

0 Kudos
Message 1 of 9
(1,722 Views)

The NI QMH templates, have a lot of weaknesses, unfortunately, which the DQMH inherits.  I've actually given two talks on some of the issues with those NI templates (both on YouTube somewhere).  You're are fighting the "do subactions by sending messages to yourself problem".  

0 Kudos
Message 2 of 9
(1,692 Views)

Hi Eric,

I'm not really the best one to give you a reply on the specific point you are raising, because DQMH or not I always been trying to avoid "playing" with enqueuing priority. Too many headaches from my experience 🙂

 

That being said, you would probably be interested in reading Tip 4 of this blog post --> https://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/ . It could be interesting to use that in some cases and avoid enqueuing messages array.

 

For your modifications, I let the DQMH architect reply.

 

 


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 3 of 9
(1,652 Views)

Hi Eric,

 

In our case, we leave high priority only for the Exit message. It is there in the code in case other programmers find they need to use it.

 

As Olivier pointed out, we normally recommend to do atomic operations and not enqueue multiple messages at a time.

 

If you feel strongly about your feature request, please add it to the feature requests board and we will consider it. We could also gauge how many more people are using enqueuing multiple messages with different priorities.

 

Thanks,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 4 of 9
(1,593 Views)

Hello Fabiola and thank you for the DQMH.

My proposal does not only concern the use case you make of this VI in the DQMH. In my project, I needed to add a loop allowing me to build a state machine powered by the MHL and so I decided to use an additional instance of your QMH to manage my state machine. And that’s when I saw the problem of priorities. I understand the proposal that you and Olivier are making to use atomic operations, but in my case, my state machine uses a lot of common cases and a few different cases with each order sent by the MHL. The atomic approach, although clearer at the debugging level, seems to me in this case brought a lot of heaviness and redundancies. Hence my wish to use a QMH. I usually use the JKI state machine, and with it, it's really easy to add states at begin or end of the queue with respect priorities. But to change, I have decided to use QMH.

Generally speaking, I find that my change, even if it does not make a real correction in DQMH use case, allows removing doubt in a more exotic use, without bringing any additional error to the DQMH. I will propose it as a future request.

Thank you again

0 Kudos
Message 5 of 9
(1,575 Views)

Just a note, but the JKI "State Machine" is a Queued Message Handler design, and not actually a true State Machine.  

 

Also, putting something on the front of a "queue" is actually "stacking" (the LabVIEW Queue can be used either as a queue or a stack).  It is not exactly the same as a true priority queue.  In a true priority queue, messages 1234 of same priority will execute 1234 even if they are not atomicly enqueued.

0 Kudos
Message 6 of 9
(1,562 Views)

Regarding state machines, if you haven't already seen them, maybe these two posts + comments on Steve Watts' blog are of interest to you - at least for comparing your needs and findings with other people's:

 

https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/Transitions-are-Important-State-Machines-Done-R...

 

https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/Parsing-State-Machines-An-Iterative-Design-Proc... (guest post by myself)




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 7 of 9
(1,558 Views)

Hi drldpowell

I'm not sure to understand the use case of priority. In Delacor_lib_QMH_enqueue Message(poly), the priority seems to put states in the stack, and in the queue if not. But in which case do you need to inject an array with mixed priorities, and why when you inject an array with all the priority, (ex: 1.2.3.4), do you end up with an order? different (1,4,3,2) as I showed in my first post?

Hi joerg

Thanks for your very interesting links.

0 Kudos
Message 8 of 9
(1,546 Views)

@Eric_BOB wrote:

Hi drldpowell

I'm not sure to understand the use case of priority. 


It is common to try and use enqueuing on front as "High Priority", but this is not a true priority queue.  It works the same as a true priority queue if one is only ever using one priority message at a time.   As you have found, it is problematic if you have multiple "high priority" messages at once.  

 

You can make a true priority queue, and the Actor Framework has one.  Personally, though, I think message priority is a code smell, used to solve problems that would be better solved another way.  In my own architectural framework, Messenger Library, I have no message priority.

 


@Eric_BOB wrote:

...and why when you inject an array with all the priority, (ex: 1.2.3.4), do you end up with an order? different (1,4,3,2) as I showed in my first post?


If you enqueue on front in the order 1,2,3,4 and the receiver is currently busy handling another message while you are enqueuing, then the receiver will (once it finishes the current message) handle them in the order 4,3,2,1.

 

However, if the receiving loop is not busy, and can start executing right away, then it will grab the first message you enqueue, 1, before you have enqueued the rest, and the final order of execution would be 1,4,3,2.

 

Actually, if the receiver could handle messages faster than you can enqueue them (unlikely but possible if there is a CPU hiccup) then you could have the orders 1,2,4,3 or 1,2,3,4.  It is actually indeterminate, which means it is a problematic design.  Also, as I said, NOT a true priority queue, which is always first-in-first-out for messages of the same priority.

0 Kudos
Message 9 of 9
(1,532 Views)