Is QMH obsolete? Am I wasteing my time?

[drjdpowell]

Comments:

1) queued message handlers are a very common design architecture, the most pure form is called the "Actor Model"

2) NI's QMH designs are poor examples of such architecture.

3) the authors of the DQMH framework deliberately use the NI QMH so people familiar with that have an easy in to understanding and using the framework.  

4) a good framework is a toolkit, not a single tool, and should cover a wide range of complexity levels.  My own Messenger Library framework can handle very simple tasks on up to multi-exe, multi-computer applications.

5) a big con of frameworks is the significant learning curve, and as they are toolkits not tools it is unwise to try and learn multiple.  Better to pick a (hopefully) good toolkit and learn it well.

[drjdpowell]

---

@johntrich1971 wrote:

---

---

I've not tried channel wires, but to me they just look like messy ways to implement queues. 

---

They are a different API for queues then the LabVIEW Queue, one that does simplify things in a block diagram.  

Unfortunately, though the NI-CMH is more readable than the NI-QMH, I don't think it solves the the significant problems of the basic design.

Events are also a queue implementation, btw.  

[johntrich1971]

---

@drjdpowell wrote:

---

Unfortunately, though the NI-CMH is more readable than the NI-QMH,   

---

To me channel wires are less readable than the QMH. When I look at the example that RTSLVU posted I was left trying to figure out which way the wires are going., and they appear to make the block diagram more messy. I can have a nice, clean block diagram or I can have a block diagram with channel wires going everywhere. Perhaps if I took some time with channel wires I would think differently, but I've just not seen the advantages. 

[crossrulz]

---

@johntrich1971 wrote:

To me channel wires are less readable than the QMH. When I look at the example that RTSLVU posted I was left trying to figure out which way the wires are going., and they appear to make the block diagram more messy. I can have a nice, clean block diagram or I can have a block diagram with channel wires going everywhere. Perhaps if I took some time with channel wires I would think differently, but I've just not seen the advantages. 

---

As I stated in another thread, I see Channels being useful for a Producer/Consumer setup (see RTSLVU's example image previous in this thread).  Otherwise, at this point in time, I am not a fan of Channels because they are too rigid.  Perhaps my next application will change my mind.

[CyGa · Accepted solution]

Hi,

QMH itself is a base design.

It is always good to know the basis when trying to use more advanced patterns / designs.

In my company, new developers start learning QMH. Not for deep understanding, but enough to get famliarized with the base concepts (2-3 days).

Then they move on learning DQMH. Knowing QMH let them understand what happens inside a DQMH module.

The DQMH framework brings quality  and homogeneity to the code across projects and developers. And it is easy to understand and debug.

So to answer the question : is it obsolete ? I'd say no ! It is still widely used.

Should you learn DQMH ? I'd say yes ! But it doesn't mean you shouldn't also take a look at the other patterns out there !

[RTSLVU]

---

@johntrich1971 wrote:

---

@drjdpowell wrote:

---

Unfortunately, though the NI-CMH is more readable than the NI-QMH,   

---

To me channel wires are less readable than the QMH. When I look at the example that RTSLVU posted I was left trying to figure out which way the wires are going., and they appear to make the block diagram more messy. I can have a nice, clean block diagram or I can have a block diagram with channel wires going everywhere. Perhaps if I took some time with channel wires I would think differently, but I've just not seen the advantages. 

---

I don't understand the confusion.

Unlike Queues, Channel Wires follow the standard Data Flow paradigm (Input on the left and output on the right). 

Queues break the dataflow paradigm.

Also With Channel Wires I don't have to pass the Queue around with shift (NOT bleep) registers and pass it through every single state of my state machine whether I am operating on the Queue or not. If I need to read or write a Channel in that state I do it, if I don't then I can ignore the Channel Wire in that state.

[crossrulz]

---

@RTSLVU wrote:

Unlike Queues, Channel Wires follow the standard Data Flow paradigm (Input on the left and output on the right). 

Queues break the dataflow paradigm.

---

I don't think "paradigm" is the word you should be using here.  Queues do not break the dataflow paradigm.  They break a convention of inputs on the left and outputs on the right.  We do that because that is how most people read.  But there is nothing inherit in dataflow that states things must go left to right.

I rarely have this problem with queues, but it really depends on how you arrange your loops

[RTSLVU]

---

@crossrulz wrote:

---

@RTSLVU wrote:

Unlike Queues, Channel Wires follow the standard Data Flow paradigm (Input on the left and output on the right). 

Queues break the dataflow paradigm.

---

I don't think "paradigm" is the word you should be using here.  Queues do not break the dataflow paradigm.  They break a convention of inputs on the left and outputs on the right.  We do that because that is how most people read.  But there is nothing inherit in dataflow that states things must go left to right.

I rarely have this problem with queues, but it really depends on how you arrange your loops

---

Well we are getting off topic here but...  IMHO: The block diagram is analogous to a schematic diagram where signal generally flows from left to right.

Queues always seemed to break that, as the Enqueue loop Queue wire "goes no where" the data makes this magical boundary jump and flows "backwards" down the Queue wire to the Dequeue loop

Channel Wires also show the "boundary jump" more clearly. 

[joerg.hampel]

@garthenar, seeing as we get asked about DQMH frequently, I collected all the advantages of using DQMH in our wiki. Please feel free to read through it.

---

@drjdpowell wrote:

5) a big con of frameworks is the significant learning curve, and as they are toolkits not tools it is unwise to try and learn multiple.  Better to pick a (hopefully) good toolkit and learn it well.

---

I couldn't agree more! Here's an excerpt from the wiki page mentioned above:

We've been heard to claim that DQMH is “our hammer”. This is true, but not in the sense of Maslow's Hammer. What we mean by this is that DQMH is a very powerful and versatile tool, and we want to use it and apply it as often as possible, to become as proficient as possible.

You can find more information on cognitive biases in Wikipedia's article on the Law of the instrument.

Regarding your original question " If I jump into DQMH before I'm any good at regular QMH will I regret it?":

I would definitely suggest to move to DQMH as soon as possible. As James said, DQMH builds on the familiar NI-QMH design so that users would recognise the familiarities and NI support people had a chance of helping with applications built on DQMH. A basic understanding of QMH is definitely helpful, but that's just about it. I don't believe the QMH is obsolete or dead - but maybe, people saw more in it than there actually is. It's just a producer consumer reference implementation, not a queued state machine or other things it has been called sometimes.

DQMH is so much more than the basic QMH design. The real benefit is in the tools that come with it: Scripting tools that automate the creation of much of the needed bits and pieces (modules, requests and testers) so that you can focus on getting the actual work done.

The VIs that the scripting tools create for you form the API that you end up using to communicate with (and from) your modules. For each DQMH module, you know exactly where to look (in the "Public API" virtual folder) to find out which public functions ("requests") it offers, and so on.

Also, there's a great community of people working with DQMH. I think it's fair to say that it's the most popular third-party toolkit/framework out there. Chances are you'll find subcontractors or employees already familiar with the toolkit. Many people are answering questions on the NI Forums (there's a separate DQMH section). Recently, the responsibility for the maintenance and development for DQMH was handed over from a single company (which did GREAT) to a consortium of people. 

I'll end this sermon with this: There are many toolkits out there, and I am sure that using one instead of recreating the same structures again and again will prove beneficial to you. Personally, I am confident that DQMH is a very good choice - actually, I'm sure it's the best, but that's just me 😉

[drjdpowell]

---

@joerg.hampel wrote:

Personally, I am confident that DQMH is a very good choice - actually, I'm sure it's the best, but that's just me 😉

---

Ah, but Messenger Library is the bestest 😉