Parallel loops in Queued State Machine not running independently

[Glibby1234]

I see, thank you! 

[Kevin_Price]

Adding slightly more to Bob's answer...

I remember reading years ago a very strong recommendation against named queues from "someone who knows things"   Can't remember who or where (either these forums or the LAVA ones), just that it was the sort of person I pretty much reflexively believed.

As I recall, there were two different points raised in the thread:

1. accidental name collision - you might intend to be creating a new queue named "queue for awesome dataz!!!", but you weren't careful enough with your naming conventions and another part of your code already created a queue with that name.  Now you have an additional reference to that same queue instead of a reference to a new queue.  Weird behavior results which may be difficult to troubleshoot if you don't account for this naming collision possibility.

2. intentional name collision - same kind of situation, but here it'd be done on purpose by a "bad actor" trying to intercept your queued data and messages.  IIRC, there was a time when 2 distinct LabVIEW executables could talk to one another via named queues.  Nice if you want it, bad if someone's trying to exploit your code.

   If you kept your queues unnamed, there was no "handle" available for anyone else's executable to reach your queues.

   This kind of direct access across the boundary of executables is no longer possible in recent LV versions.

Having said all that, as we've built up utilities to support our regularly reused QMH architecture, we've nevertheless adopted the policy of naming our queues *solely* to be able to identify and cross-reference them when using the Desktop Execution Trace toolkit.

- Kevin Price

"do as I say, not as I do"

[wiebe@CARYA]

---

@Kevin_Price wrote:

we've nevertheless adopted the policy of naming our queues *solely* to be able to identify and cross-reference them when using the Desktop Execution Trace toolkit.

---

If the probe window can identify a queue by the label of the wired data type, the DETT should be able to do it. Of course, the names of the labels can't be changed dynamically, so perhaps that would be a reason to name queues.

If an entire framework is build on named queues, at least every user would be aware of this. So accidents might actually be less likely.

I've seen bugs where a library named it's queue 'Main', and a user interface template named it's queue after the top level VI (minus .vi). Bad things happened when someone named it's top level GUI "Main.vi"...