Implementing synhronized access to shared objects

[bsvingen]

I have been reading the manual (for a change ) and unless the manual i factually wrong we already have full locking capability on by default. Non-reentrant sub VIs only operate serialized, one at a time, thus it is impossible to create any problems, at least it is impossible if all parallel code is placed in non-reentrant sub VIs.

Also, a reentrant functional global called by a call-by-reference node (the closest thing to a call by ref object in "native" LV), will *never* operate in parallel for the same reference.

I'm just mentioning this because it makes it quite clear that "someone" has done a job thinking this through and made some decisions. The result of that thinking is more in the line of "better safe than sorry".

A by-ref object will be different (as i have understood by now). However, untill recently i have never really understood what the problem was. I have used call by ref LCODs for years, and since that is a reentrant functional global called by CBR, it is 100% safe because it operates serially - allways (for the same reference).

But isn't then the obvious answer to the sunchronisation debate quite clear? A call by ref object must be made 100% safe in the same manner as a reentrant VI called by a reference node is 100% safe for the same reference, and in the same manner as the default for sub VIs is non-reentrant. Then, if you want it "super-reentart" by-ref object, you are on your own and must use the already available locking and synchronisation VIs that exist, but use it manually. I mean, if you are so good a programmer that you actually know under which circumstances multithreading is an advantage, then you also know what to do and how to do it with regard to making it safe. The rest of us wouldn't notice the difference, and will be more than happy with a by-ref system even though it was 100% serialized.

[robijn]

I have been reading the manual (for a change ) and unless the manual i factually wrong we already have full locking capability on by default. Non-reentrant sub VIs only operate serialized, one at a time, thus it is impossible to create any problems, at least it is impossible if all parallel code is placed in non-reentrant sub VIs.

Indeed, it is safe from itself. But when you retrieve such an object from some kind of repository (a FG for example) and use it, you get into exactly the same trouble as with a reference. Or actually more problems, because it takes more time (and code) to execute the modifications if you have a retrieve-modify-store system (with a containing wire) than if you have an immediate attribute change (with a referencing wire). And you get lots of code replication.

That's why I think NI's argument that concurrency problems cannot occur because a containing wire is used, is not telling the whole story and actually incorrect.

Now you might say: "then just don't use a repository". The problem is that that is what we want the objects to be accesable from multiple places, and we're back at the reason why the whole ref/no-ref debate started.

But isn't then the obvious answer to the sunchronisation debate quite clear? A call by ref object must be made 100% safe in the same manner as a reentrant VI called by a reference node is 100% safe for the same reference, and in the same manner as the default for sub VIs is non-reentrant. Then, if you want it "super-reentart" by-ref object, you are on your own and must use the already available locking and synchronisation VIs that exist, but use it manually. I mean, if you are so good a programmer that you actually know under which circumstances multithreading is an advantage, then you also know what to do and how to do it with regard to making it safe. The rest of us wouldn't notice the difference, and will be more than happy with a by-ref system even though it was 100% serialized.

I hope more people will see it like this. The basic use (for a starter in LV) should be simple and 100% safe, and under most-often-occuring conditions also fast. If you want more performance you can accomplish that by writing your own locking. I hope NI will some day seriously consider the alternative I present, it meets these criteria. I am more than willing to tell them all the details about it, I have no patents on it It is in my own interest that NI finds a good solution.

Joris

[bsvingen]

Indeed, it is safe from itself. But when you retrieve such an object from some kind of repository (a FG for example) and use it, you get into exactly the same trouble as with a reference. Or actually more problems, because it takes more time (and code) to execute the modifications if you have a retrieve-modify-store system (with a containing wire) than if you have an immediate attribute change (with a referencing wire). And you get lots of code replication.

Yes, but not if you use the LCOD approach. See "A Software Engineering Approach to LAbVIEW" by Jon Conway and Steve Watts where the LCOD principle is explained. LCOD stands for LabVIEW Component Oriented Design. With LCOD there is no retreive - modify - store, because the modification is done inside the functional global, directly on the variables. See also this post.

[robijn]

Wire level synchronization

What I propose is the following. An unbundle node could either be normal or "synchronized". A synchronized unbundle would guarantee the access to the private data members in synchronized manner. All data wires originating from synchronized unbundle would be of synchronized type, in a little similar manner as a dynamic dispatch wire is of special dynamic dispatch type. Such a wire must evetually be connected to a bundle node. When the wire is bundled back to the originating object, the synchronization requirement is released.

Hi Jimi,

I've let your sync'ed wire ideas simmer for a couple of days. Your wires may be very nice for situations which I called locking for specialistic cases. Things you cannot accomplish with some standard ("automatic") locking scheme. Your wires would indicate the data in the wires is kind-of shielded from outside influence.

My own ideas are for a different part of the locking world, for "automatic" locking.

O'Haskell synchronization implementation is an example of this. Integrating the synchronization directly to the user interface allows NI to change the mehcanisms under the hood, when computer science comes up with more advanced methods.

It is difficult/impossible to make something as complex as the access locking implementation independent. I don't know O'Haskell. I do know that it cost me months to work out and implement my locking idea 4 years ago. I think to have a good implementation you should say "ah that actually sounds logical" when somone explains in two sentences how something works, no matter how complex it is internally. The best systems can be used in an obvious way. Your wires have the potential to be like that.

There will probably be technical problems in allowing the user to connect such a synchronized wire to all existing VIs since these VIs. Therefore the programming model for all nodes that do not support such synchronized wires will be branching the wire and passing the non-synchronized wire branch to the node and then bundling the result back to the synchronized wire.

Hmm, you are thinking about what needs to be done if the called subVI would also need to use this locked data ? Should be solvable though... I guess it can be tracked whether the calling VI was the VI that contained the synch'ed wire.

Also deadlocks can occur because you do locking on object level. I think you have to clear some obstacles on paper to get this working.

Joris