"Breakeven point" for using AMC messages vs. FGVs to send/receive data

[abvenk]

Hi all,

I'm using LabVIEW 2016. I have a medium-sized application where I'm using AMC (asynchronous messaging communication) library to send and receive messages and data between multiple local threads (VI's on the same machine). 

Initially I used a lot of FGVs to send data to the UI thread from other threads for display, keeping the UI thread free of incoming messages. The FGVs are read in the timeout case (timeout=10ms) of event structure in the UI thread. Then I got a suggestion to use messages in the UI thread as well to maintain consistency and to reduce CPU usage due to repeated reading of FGV data every 10ms. The rationale was that the asynchronous messages would theoretically be processed only when received, not necessarily every 10ms. (The fastest rate in the application is currently 25ms, which could change later depending on system changes).

So far I don't see the benefit of using messages in the UI thread in terms of reducing CPU usage. I'm thinking the overhead of flattening/unflattening from/to XML in the messages is adding to CPU usage, that I can get rid of using FGVs. 

Is there such a thing as a "breakeven point" of say, number of individual messages or number of individual data packets (i.e. 1D array, 2D array, etc) when you might say "less than 10 -- use messages, more than 10 -- use FGVs".

Sorry, uploading code is not feasible, but I think this is a pretty general topic.

Would appreciate any pearls of wisdom on this issue! 

[crossrulz]

I am not familiar with the AMC (I know it exists, I just haven't played around with it).  Personally, I like to use User Events to send updates to the UI loop.  They work with the Event Structure, so no timeouts required.

My second choice, based purely on what you have told us so far, would be to use a Global Variable instead of the FGV.  Simpler, more performant.

[abvenk]

---

@crossrulz wrote:

I am not familiar with the AMC (I know it exists, I just haven't played around with it).  Personally, I like to use User Events to send updates to the UI loop.  They work with the Event Structure, so no timeouts required.

My second choice, based purely on what you have told us so far, would be to use a Global Variable instead of the FGV.  Simpler, more performant.

---

Aren't we advised against using Global Variables to avoid race conditions? At least when I took the courses globals were a strict taboo 

Also, are user events suitable for high speed update of graphs? Like I mentioned the fastest rate in my application is 25ms.

Thx

[mcduff]

Queues are the fastest, but User Events are an extremely close second.

I usually use User Events to communicate between loops and second crossrulz's suggestion.

Globals only cause race conditions if used incorrectly, that is, you are reading and writing from multiple place. If write once read many, then no race conditions. If you program correctly and only write and read in specific places in a well defined way, then no race conditions. Race conditions happen because people abuse global variables.

mcduff

EDIT: Please check out this excellent presentation regarding User events

https://libraries.io/github/JackDunaway/LabVIEW-User-Events-Tips-Tricks-and-Sundry

[crossrulz]

---

@mcduff wrote:

EDIT: Please check out this excellent presentation regarding User events

https://libraries.io/github/JackDunaway/LabVIEW-User-Events-Tips-Tricks-and-Sundry

---

Do note that Events got a MAJOR update the year after that presentation.  I know there is at least one "bug" mentioned in that presentation that was fixed as part of that update.

---

@mcduff wrote:

Globals only cause race conditions if used incorrectly, that is, you are reading and writing from multiple place. If write once read many, then no race conditions. If you program correctly and only write and read in specific places in a well defined way, then no race conditions. Race conditions happen because people abuse global variables.

---

See this very excellent NI Week presentation (the presenter is a freakin' genius ): Are Global Variables Truly Evil?

[crossrulz]

---

@abvenk wrote:

Also, are user events suitable for high speed update of graphs? Like I mentioned the fastest rate in my application is 25ms.

---

That is SLOW.  User Events will have no trouble what-so-ever.

[abvenk]

Thanks guys for the good discussion and tips. I will definitely look into user events in more detail.

AMC has worked well for me the last couple times, and my application is already architected using AMC queues/messages. I would like to still get some user experience stories from folks who have used AMC vis-a-vis FGVs. 

AMC was recommended by a CLA a while back. It doesn't seem to enjoy the popularity it deserves, IMHO. 

[abvenk]

---

@mcduff wrote:

Queues are the fastest, but User Events are an extremely close second.

I usually use User Events to communicate between loops and second crossrulz's suggestion.

Globals only cause race conditions if used incorrectly, that is, you are reading and writing from multiple place. If write once read many, then no race conditions. If you program correctly and only write and read in specific places in a well defined way, then no race conditions. Race conditions happen because people abuse global variables.

mcduff

EDIT: Please check out this excellent presentation regarding User events

https://libraries.io/github/JackDunaway/LabVIEW-User-Events-Tips-Tricks-and-Sundry

---

Yes, I agree race conditions happen when globals are abused. I'm very careful with where and how I read/write to globals. But FGVs are definitely cleaner and allow for flow control through error wires. To do that with globals, we'd have to wrap them in sequence structures, an overhead and another "taboo" per NI. 

[billko]

---

@abvenk wrote:

Thanks guys for the good discussion and tips. I will definitely look into user events in more detail.

AMC has worked well for me the last couple times, and my application is already architected using AMC queues/messages. I would like to still get some user experience stories from folks who have used AMC vis-a-vis FGVs. 

AMC was recommended by a CLA a while back. It doesn't seem to enjoy the popularity it deserves, IMHO. 

---

Betamax.  'nuff said.  😉

[abvenk]

---

@billko wrote:

---

@abvenk wrote:

Thanks guys for the good discussion and tips. I will definitely look into user events in more detail.

AMC has worked well for me the last couple times, and my application is already architected using AMC queues/messages. I would like to still get some user experience stories from folks who have used AMC vis-a-vis FGVs. 

AMC was recommended by a CLA a while back. It doesn't seem to enjoy the popularity it deserves, IMHO. 

---

Betamax.  'nuff said.  😉

---

So..... betamax == AMC?