LabVIEW
Using Network Streams to share data between VIs on the same PC
Solved!
@Sipic wrote:
Conclusion: FGVs are truly evil!!!
As are Black Knights. I'll take you to task on some of your points Crossrulz.
Ben's nugget is really good and I completely get what is being said. I'm trying to work out which is the original/old term, an AE or an FGV but it doesn't matter. They both do what I want them to do. Pass data with a low programming overhead and no race conditions.
As I said in my reply to Ben the word 'Functional' means just that. There is some 'optional' functionality that can be incorporated in the data transfer mechanism so arguing about the semantics of what it's called misses the point of the response.
An FGV is not in any way the same as a Global Variable. The risk of Race Conditions 'does' exist even if it didn't happen in your benchmarking.
A Global Variable 'may' be faster on it's own but if you incorporate a mechanism to avoid the race conditions then you lose performance.
Almost every practical LabVIEW developer I know uses them (FGVs) ergo.....FGVs are flipppin wonderful.
"Vanilla" FGV are subject to the same race conditions as a global. Namely it can be written to and read from from anywhere, any time. The AE avoids this by having all data changes inside the FG. The only (fuctional) difference I can see is that a FGV is a bit easier to incorporate into your dataflow than a global.
Indeed, the Functional Global was invented in a time before globals to do the same thing. Hence the name "Functional Global".
Sipic wrote:
An FGV is not in any way the same as a Global Variable. The risk of Race Conditions 'does' exist even if it didn't happen in your benchmarking.
A Global Variable 'may' be faster on it's own but if you incorporate a mechanism to avoid the race conditions then you lose performance.
As I defined it in my previous post, a FGV is functionally exactly the same as a global, just slower. And the race condition I mentioned (Read-Modify-Write) is an issue with both FGV and Global Variables. I never said race conditions did not exist. By protecting the critical sections in an Action Engine, you have prevented the Read-Modify-Write race condition. Yes, with parallel processes, you have the race condition of which will happen first. That cannot be avoided in parallel processing. But at least you will not do the modify-write with old data when you use an Action Engine.
And I do have to argue about semantics because we will be talking in circles if we do not agree on terminology. That was half of the point of my previous post: to make sure we were talking about the same thing. The other half of my point was that the Get/Set Action Engine with no other cases (what I have defined as a FGV) is functionally exactly the same as a global, but slower.
@Sipic wrote:
Almost every practical LabVIEW developer I know uses them (FGVs) ergo.....FGVs are flipppin wonderful.
Just to show that I think we are actually on the same page: if you look at my benchmarking, the Action Engine was actually faster than the local variables and previented the race condition. And I did add semaphores to the global variable benchmark at one point (might be in my NI Week presentation) and it was horribly slow. I realized why I hated semaphores so much. So Action Engines are indeed flippen wonderful!
