a) R&D has a long laundry list we brainstormed ourselves of nodes to create as pairs on IPE. This is on the list.
b) It seems like a great idea on its face.
c) We assume the mutex locking would be the hard part.
c0) To lock on fields would likely have to mean this runs in the UI thread for all Control and VI properties and stalls other UI operations because we wouldn't know what fields any given operation would touch and having a lock on every individual field would be expensive.
c1) Even if we get a more granular lock, what is the meaning of this lock from the user's point of view? Are only these fields locked out or is all edits to the object locked out and these are just the fields that happen to be changing? What if the object is part of a larger object (like a Numeric inside a Cluster)... is the Cluster intended to be locked?
c2) Hard to say what to do if reference goes stale while lock is held. Pure software objects we can just defer killing the reference, but network references and hardware references would be an issue.
c3) Locks on remote machines are tricky and obviously cannot be operated on "in place" unless we're being extra clever and such notation means sending code over the network to execute over there.
c4) Other refnum types might not be sufficiently under our control, so not all types would be able to use this (.NET refnums come rapidly to mind, probably many hardware APIs).
Seems like a good idea, but there's a lot of technical work that would have to be done.
Perhaps we could enable it with a deeply hidden option in NI config files, it would come with a big warning on locking issues. For basic UI controls it wouldn't be a big deal but I agree that it can become complicated for you.
jchretien: No, for basic UI controls it is a very big deal. The others are just worse. And, no, we wouldn't add this as a config option. We used to do that sort of thing back in the day when we considered (foolishly) config tokens to be private things that users didn't know about. We haven't added that sort of "use at your own risk" functionality in quite some time. I doubt we ever will again.
The locking seems important, because in the top code, there could easily be race conditions if the same property is also written in other places in parallel. The two code fragments are not equivalent in this respect.
I am not sure why the IPE is used in the upper example at all. Wouldn't it be easier to simply add a cluster diagram constant consisting of [1, -1].
> I am not sure why the IPE is used in the upper example at all. Wouldn't it
> be easier to simply add a cluster diagram constant consisting of [1, -1].
Altenbach: Obviously this is an example. There are plenty of reasons why you would be making changes to subregions of a cluster control value in-place. This merely exemplifies the analogy between the cluster editing and the property editing.
I dont quite see the use, it's not alot leaner code and InPlace is meant to tell the compiler to work in-place in the memory, which such a small operation should do anyway. Still, i woulnd't mind it. 🙂
/Y
G# - Award winning reference based OOP for LV, for free! - QestitVIPMGitHub
> I dont quite see the use, it's not alot leaner code and InPlace is meant to tell the compiler
> to work in-place in the memory, which such a small operation should do anyway.
That is provably impossible for the refnum code. No compiler however intelligent can tell some types of programmer intent.
In VI Alpha, you read the Value property, do some computations, then write the Value property.
In a parallel VI Beta, you also read the same control's Value property, do some computations, then write the Value property.
The code for Alpha has no idea whether or not Beta exists. It has to compile to assume that parallel execution *could* be happening. Now, there are three ways to compile Alpha:
Alpha could copy the value out, modify the copy, and then copy the result back in OR
Alpha could obtain a lock for the memory location, do its work in place, then write the result back OR
Alpha could assume that it will always be called in a special UI thread where cooperative multitasking has been disabled.
Case #3 cannot be assumed by the compiler -- that requires the programmer to explicitly say "I want this VI to hog the UI thread completely, so in VI Properties, I will mark it as Subroutine priority AND run in UI thread". This means the entire UI will completely hang while that VI is executing, but it does provide security for the shared memory location.
Case #2 and #1 are more interesting. There is nothing on the block diagram that says that this read and this write are meant to be atomic relative to the rest of the code. If LabVIEW were to make that assumption, we run into problems. The code between that read and that write may be open ended, i.e. a while loop with no guarantee of a termination. There are plenty of use cases for reading from a configuration and then going into a long process loop before writing the finished configuration back. Things become more complicated if the Write is done conditionally (either because the write is inside a case structure or has the error wire connected to it)... if the write is conditional, then the original value needs to be preserved anyway, so a copy still has to be made.
Given all of that, the only option that LabVIEW has is to compile a refnum read completely independent from its surrounding code UNLESS there is a structure node that indicates the duration that the lock should be held and which guarantees that the write will occur -- because working in place means that the write is happening continuously.
The IPE node actually specifies a whole lot of behavior for clusters and classes and other non-refnum types that cannot be discovered from diagram analysis. LabVIEW DOES optimize those cases that can be discovered to be inplace, but there are cases where multiple conflicting optimizations are possible. More information from you about your intentions for a diagram (particularly for swap operations) helps LabVIEW know what type of optimization you would prefer. My personal favorite is the destructive unbundle -- when you unbundle a large array from a cluster and you're ok with modifying the original cluster in order to just take that large array. You need to use the IPE to do this and replace it with a swapped-in empty array to avoid copying the inner array. Otherwise, LV looks at your code and says, "This clearly wants me to preserve the value of the cluster and extract the element, so I'm going to have to make a copy."
