Atomic message enqueuing in DQHM

[Rafal_Kor]

I know messages enqueued one after another in MHL may not execute in the intended order because someone or something may enqueue something in between. What would be wrong then with enqueuing the intended sequence of messages (states) from within the EHL? such that if anything else enqueued something on the MHL queue, it would be enqueued after the intended sequence?

[Taggart]

If I understand correctly:

You want something like a batch command?

If you are enqueueing the series of commands 1 at a time inside the EHL, you should be careful that you are not enqueueing anywhere other than the EHL, for example in a helper loop or another case in your MHL.

I would recommend not serially enqueuing a bunch of states serially in the EHL.  What I would recommend is make each case inside your MHL into a subvi.  (ie. "A" calls subvi A, "B" calls subvi "B", ect) Then if you have a "batch" command that is to execute ABC, just enqueue a command "batch" in the EHL loop.  In the MHL loop the case structure for "batch" would just call A, B, C serially.

Hopefully that is clear.  Sorry I'm on a computer at the moment that doesn't have LabVIEW installed, so I can't throw up any example code.

I talk about this in this blogpost: https://delacor.com/simple-dqmh-dos-and-donts/  Look for the section titled: Do make MHL actions atomic

[Rafal_Kor]

I think you got my question correctly. I was just staring at some labview code for a project I'm working on, and this "brilliant" idea occurred to me, so I figured I would ask. Now if I understand your answer correctly, and supposing that I do enqueue elsewhere in addition to EHL, suppose I enqueue a bunch of messages in another case of MHL that is being executed at the moment when the EHL tries to enqueue its sequence of messages. Are you saying that even though the message states would be coded to enqueue in series in the EHL, because this other case of the MHL was also attempting to enqueue its own series of messages, the actual order of messages on the queue would end up getting all jumbled up and not be what I would expect, namely, all the messages enqueued by EHL followed by all the messages enqueued by this other case of MHL.

[Taggart]

Yes that is exactly what I am saying.

[Taggart · Accepted solution]

More precisely I am saying you can't predict what order they would end up in.  It is indeterminant.

[Rafal_Kor]

Thank you for the clarification. I guess my question shows what may happen when one stares at labview code for too long.

[Ozfarmboy]

Another approach is to create a state machine inside a MHL case.

See tip 4 of Fab's post here: https://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/ 

[Rafal_Kor]

Thank you, as I've seen all the referenced blog post. I was just looking at some laview code and my mind started to wander in a day dream about what if. Thank you for slapping me awake.

[danny_t]

I know this is a little late for a reply, but I will add the comment that I have on a couple of occasions, placed a JKI state machine subVI into the MHL.

I had a User Login Module already written as JKI state machine, lots of GUI user interface stuff and guided questions. I want this same interface but within a a DQMH module and I found it work well putting the existing state machine within the "add user" or similar MHL case. This worked well as it was OK to block the rest of the DQMH requests (like delete user) because there was a big popup GUI on the screen that the user had to react with before they could continue. 

The only additional thing I needed to do with the JKI state machine to registrar it to the DQMH STOP message so that I could externally close this popup GUI and then stop the DQMH if required.

[Rafal_Kor]

I've started using jki state machines too. Your idea is a pretty good one.