Delacor Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Atomic message enqueuing in DQHM

Solved!
Go to solution

Atomic message enqueuing in DQHM

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?

0 Kudos
Message 1 of 9
(626 Views)

Re: Atomic message enqueuing in DQHM

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

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
Message 2 of 9
(613 Views)

Re: Atomic message enqueuing in DQHM

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.

0 Kudos
Message 3 of 9
(607 Views)

Re: Atomic message enqueuing in DQHM

Yes that is exactly what I am saying.

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
0 Kudos
Message 4 of 9
(599 Views)
Solution
Accepted by topic author Rafal_Kor
12-04-2018 01:14 PM

Re: Atomic message enqueuing in DQHM

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

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
Message 5 of 9
(598 Views)

Re: Atomic message enqueuing in DQHM

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

0 Kudos
Message 6 of 9
(587 Views)

Re: Atomic message enqueuing in DQHM

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/ 

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au
Message 7 of 9
(585 Views)

Re: Atomic message enqueuing in DQHM

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.

0 Kudos
Message 8 of 9
(580 Views)

Re: Atomic message enqueuing in DQHM

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.

Danny Thomson
Message 9 of 9
(17 Views)