DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

When does a module become a listener to another module’s broadcasts?

Solved!
Go to solution

Hello, and thank you for all the effort you have put into this great toolkit!

 

I have a question about when a module becomes a listener to another module’s broadcasts.

As an example, I have a DQMH module named “Video Stream” that has a lot of different broadcast events. Some of the events also broadcasts large amount of data.

The “Video Stream” module has broadcast events that are interesting to several other modules, so I’ve added the “Obtain Broadcast Events for Registration.vi” to all relevant modules, like in the image below.

 

Registration.png

 

 

But not all broadcasts from the “Video Stream” module are interesting for all the other modules where its broadcasts are registered. Most of them are only interesting in the status for the module etc., while only one other module is interesting in the broadcast event containing the large amount of data.

 

I’ve read that if nobody listens to broadcasts from a module, no event queues are created, and hence no memory leakage. But when is the event queue created?

In the image above, only empty refnums are wired to the event registration, so no event queues are created there.

 

But what about the image below? Here the module is started, and the dynamic event registration is updated with the actual user event refnums.

Does this module now become a listener to ALL the broadcast events from the “Video Stream” module, and hence memory is located for all broadcasts, or only the broadcasts that are handled in this EHL by adding an event case for the specific broadcast event?

 

Start video stream.png

Download All
0 Kudos
Message 1 of 6
(1,780 Views)

The "Reg Event" in your first image is creating an event queue, even if the User Events registered to it aren't valid.  "Reg Events" in your second image, some valid User Event are registered.

 

A "memory leak" will only happen if events go on the queue without being handled.  An Event Structure handles events (if the structure has no case for a specific event, the event is still handled as a no-op).

 

 

Message 2 of 6
(1,722 Views)

Thanks a lot for your reply, @drjdpowell . Highly appreciated.

 

So; this means that event queues are created for all broadcasts from a module when wired to “Reg Event”, as in the first image? And each broadcast event will have its own event queue?

 

If that’s the case, the I presume that memory will be allocated for all broadcasts from a module if registered in another module, even if only some of them are handled by the EHL? And hence, broadcast events with large payload will be queued to the EHL and handled as a no-op, even if it has no case for that specific broadcast event?

0 Kudos
Message 3 of 6
(1,713 Views)

Just to add, I think the original developers of the Event System API in LabVIEW made a poor choice in downplaying the Event-queues (which they called "event registration refnums" I think, rather than something with "queue" or "buffer" in the name).  This leads to people having difficulty getting an intuitive understanding of how events queues work, and this leads to a lot of confusion.  Events, actually, aren't that complicated.  

Message 4 of 6
(1,711 Views)
Solution
Accepted by BjornH

@BjornH wrote:

So; this means that event queues are created for all broadcasts from a module when wired to “Reg Event”, as in the first image? And each broadcast event will have its own event queue?

 

If that’s the case, the I presume that memory will be allocated for all broadcasts from a module if registered in another module, even if only some of them are handled by the EHL? And hence, broadcast events with large payload will be queued to the EHL and handled as a no-op, even if it has no case for that specific broadcast event?


Correct.  You explicitly created an event queue to handle all those User Events.  That you later provide an Event Handler that does nothing with some of those events is your choice; the compiler is not a mind reader.   If you don't want to queue up some Events, then don't Register the entire Cluster of User Events; just Register for those you want to handle.

 

Note, though, that I believe the Event system may have memory-optimizations where it only has one copy of an event even when multiple Event Queues are registered for it, so you might not have to worry about memory as much as you are doing.  Can't recall where I got this belief; you might want to do some memory-use performance benchmarks. 

Message 5 of 6
(1,705 Views)

@drjdpowell wrote:


Note, though, that I believe the Event system may have memory-optimizations where it only has one copy of an event even when multiple Event Queues are registered for it, so you might not have to worry about memory as much as you are doing.  Can't recall where I got this belief; you might want to do some memory-use performance benchmarks. 


I have the same belief, and our benchmarks seem to confirm this (although I find these things hard to benchmark tbh).




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 6 of 6
(1,695 Views)