LabVIEW
Can you think of a scenario where the use of Request Deallocation could cause a race condition / stale data?
I don't think it could, but I'm not sure. It's much more likely that it recompiled differently and now what needs to win the race is winning.
Use of Request Deallocation is extremely seldom useful (my guess is it’s below 0.01%). Outside of this rare unicorn case it is at best making the work of the LabVIEW compiler a lot more difficult, and always a performance nightmare!
it could also expose a bug in LabVIEW with data being handled unsafe but that is extremely unlikely. Such unsafe data handling would in one way or the other be exposed without Request Allocation too, and rather sooner than later!
But your code almost certainly has races somewhere.that by pure chance were seemingly “fixed” by the removal of one or more of those nodes. My educated guess is that whoever wrote that program found out by accident that adding a Request Deallocation magically fixed their race induced problem and from then on got the get to go method of “fixing” any strange results, rather than getting rid of concurrent global data access.
After seeing AQ's E-CLA presentation (don't remember its name), I learned that the use-case for "request deallocation" is so extreme that it should in practice never be used. How it ended up in the palette is a mystery. The context help misguides the user into thinking that it is a good thing to sprinkle the code with this node.
@rolfk wrote:
Use of Request Deallocation is extremely seldom useful (my guess is it’s below 0.01%). Outside of this rare unicorn case it is at best making the work of the LabVIEW compiler a lot more difficult, and always a performance nightmare!
In my 20 years of LabVIEW experience, I have successfully used Request Deallocation once. Even then, I'm not completely sure I was using it correctly (it was ~15 years ago and I don't have access to the code to see if I could handle the data better).
@crossrulz wrote:
@rolfk wrote:
Use of Request Deallocation is extremely seldom useful (my guess is it’s below 0.01%). Outside of this rare unicorn case it is at best making the work of the LabVIEW compiler a lot more difficult, and always a performance nightmare!
In my 20 years of LabVIEW experience, I have successfully used Request Deallocation once. Even then, I'm not completely sure I was using it correctly (it was ~15 years ago and I don't have access to the code to see if I could handle the data better).
I never used it beyond doing some experiments and never saw a program where it was used in a useful way. When I saw it it was always to "fix" poor programming practices like race conditions caused by globals being accessed concurrently. Except that those "fixes" often started misbehaving after doing seemingly unrelated edits or updating the software to a newer LabVIEW version.
@rolfk wrote:
@crossrulz wrote:
@rolfk wrote:
Use of Request Deallocation is extremely seldom useful (my guess is it’s below 0.01%). Outside of this rare unicorn case it is at best making the work of the LabVIEW compiler a lot more difficult, and always a performance nightmare!
In my 20 years of LabVIEW experience, I have successfully used Request Deallocation once. Even then, I'm not completely sure I was using it correctly (it was ~15 years ago and I don't have access to the code to see if I could handle the data better).
I never used it beyond doing some experiments and never saw a program where it was used in a useful way. When I saw it it was always to "fix" poor programming practices like race conditions caused by globals being accessed concurrently. Except that those "fixes" often started misbehaving after doing seemingly unrelated edits or updating the software to a newer LabVIEW version.
My exact scenario was due to a VI needing to analyze a very large data set and we wanted to clear that out when the analysis was complete. Again, I may have been able to do better with tricks I have learned over the years.
