Alternative for Queue in SubVI

[Ben]

I did not see any queue operation sin your screen shots.

What did I miss?

If you create a queue you have to destroy it. If you put data in the queue it should flushed if it has any data left in it.

There is a small amout of memory resreved when a queue is created ( a handful of bytes) and if queues are eing repeatedly created and destroyed in a tight loop, expect memory to be consumed.

Better to create a queue once and use it as long as possible flushing instead of destroying etc....

Ben

[RavensFan]

Every reference to a named queue is a new reference to the same queue.  If you keep creating new references without deleting them, then you do have a memory leak.

---

@mark_wer wrote:

---

yes it's maybe no bug, but it's not the right thing for my purpose either. I want to do as much as possible in the SubVI so I can not obtain the Queue in the Main VI and pass it to the SubVI. It's also not possible to close the queue in the SubVI again, because then I lose the purpose of what i want to achieve with the Queue. That's why i was asking for an alternative 🙂 I

---

You can close the queue reference within the subVI.  Closing that one reference to a named queue is not killing the queue (unless you wired a True to the Force Destroy? input.)  The queue will remain and still contain everything else that has been fed into it.

It still seems unnecessary to obtain and release a queue on each iteration of a subVI.  I would recommend using a functional global variable or Action Engine obtain, store, and release references to the queues.  That way the subVI can grab the reference to the already obtained queue from the FGV whenever it needs it.

[Bob_Schor]

I'm trying to wean myself from Queues, but I generally use a Queue Action Engine that does all of the Queue functions except Dequeue.  Each Action Engine "encapsulates" a particular Queue, with the Queue wire existing entirely inside the AE except when wired to the Dequeue Element (as shown in the Snippet).  Because of this, none of the Queues need to be named -- the only caution is to call Initialize once before doing other Actions.  Indeed, you could "fancy up" the AE to eliminate the need for Initialize -- if the Queue doesn't exist, create it, but that was more complicated than I wanted to make it.

This Queue is for a Queued Message Handler, and as the AE suggests, it handles the "Do" messages.  The default Action, illustrated by the second call, is Enqueue.  This sits right outside the QMH (the While Loop and Case Statement are visible to the right), so it exports the Queue to the QMH's Dequeue function.

[An embarassing note -- when I first had this idea, I put the Dequeue as an Action, as well.  It didn't take long to see that this was a really Stupid Idea ...].

Bob Schor

[Bob_Schor]

---

@mark_wer wrote:

---

I want to do as much as possible in the SubVI so I can not obtain the Queue in the Main VI and pass it to the SubVI. It's also not possible to close the queue in the SubVI again, because then I lose the purpose of what i want to achieve with the Queue.

---

Why not?  You wouldn't even need a Named Queue if you did it that way, simply pass the Queue itself into the sub-VI (One Queue to Rule Them All, One Queue to Bind Them ...).  If you enqueue outside the sub-VI, then the elements will be available inside the sub-VI, and if it only processes, say, half of them before exiting, the rest will be waiting in the Queue when it is called again.

There was another topic discussing Queues today where the idea of storing the Queue (and its reference) inside an Action Engine was discussed -- I call this a "Wireless Queue" ...

Bob Schor

[Ben]

---

@Bob_Schor wrote:

...

[An embarassing note -- when I first had this idea, I put the Dequeue as an Action, as well.  It didn't take long to see that this was a really Stupid Idea ...].

Bob Schor

---

Because the AE was locked up and nothing could be queued?

Ben

[Ben]

---

@Bob_Schor wrote:

---

@mark_wer wrote:

---

I want to do as much as possible in the SubVI so I can not obtain the Queue in the Main VI and pass it to the SubVI. It's also not possible to close the queue in the SubVI again, because then I lose the purpose of what i want to achieve with the Queue.

---

Why not?  You wouldn't even need a Named Queue if you did it that way, simply pass the Queue itself into the sub-VI (One Queue to Rule Them All, One Queue to Bind Them ...).  If you enqueue outside the sub-VI, then the elements will be available inside the sub-VI, and if it only processes, say, half of them before exiting, the rest will be waiting in the Queue when it is called again.

There was another topic discussing Queues today where the idea of storing the Queue (and its reference) inside an Action Engine was discussed -- I call this a "Wireless Queue" ...

Bob Schor

---

In LVOOP I think it is called  "Singlton".

Ben

[Bob_Schor]

---

@Ben wrote:

---

@Bob_Schor wrote:

---

There was another topic discussing Queues today where the idea of storing the Queue (and its reference) inside an Action Engine was discussed -- I call this a "Wireless Queue" ...

Bob Schor

---

In LVOOP I think it is called  "Singlton".

Ben

---

Wow.  The Singleton is one of the Gang of Four's Design Patterns.  I'm embarassed that I didn't recognize that the Wireless Queue was of this type ...

Bob "Always Learning" Schor