Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Wire level reentrancy
Tomi_Maila
Active Participant
08-27-2006 08:07 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Wire level reentrancy
New issues seem to pop up. It seems that each class has only one instance of each member method data space. For reentrant methods there is a separate dataspace for each reentrant instance of the method. However dynamically dispatched methods cannot be reentrant. There is defenitely a need for reentrant dynamically dispatched VIs, Aristos Queue already said earlier that NI is trying to solve this issue.
Dataflow OOP has however raised a need for totally new kind of reentrancy, that is wire level reentrant VIs. NI chose to implement OOP in dataflow ideology resulting in LVOOP. In traditional dataflow, wires carry only data. However in LVOOP wires carry also methods and functions. The problem is that in traditional dataflow each wire is totally unrelated to any other wire. In LVOOP wires may share same methods and functions as well.
This raises new kinds of problems. If on one wire a method is called, then all the other wires of the same type have to wait for this method to exit before they can call the same method. This problem can be solved by allowing dynamically dispatched methods to be reentrant in classical way.
The other problem is that shift registers and front panel values become global to the class. Sometimes this is a desired result but in may cases this defenitely is not what programmer wants. Traditional reentrancy would make shift registers and front panel values local to some node on block diagram. This may also be a wanted result, but in a dataflow thinking one may also want the shift register values and the front panel control values to flow with the wire. That is when ever wire is branched, also copy of each VI dataspace is created. This wire level reentrancy is totally new kind of reentracy for which there was no need before dataflow OOP. In this ideology the dataspaces of selected class methods would flow with the wire. Of course the compiler may choose not to copy the dataspace if it is not used or copy only those parts of the dataspace that may be modified elsewhere.
Please NI, pimp my next version of LabVIEW to include wire level reentrant methods.
New issues seem to pop up. It seems that each class has only one instance of each member method data space. For reentrant methods there is a separate dataspace for each reentrant instance of the method. However dynamically dispatched methods cannot be reentrant. There is defenitely a need for reentrant dynamically dispatched VIs, Aristos Queue already said earlier that NI is trying to solve this issue.
Dataflow OOP has however raised a need for totally new kind of reentrancy, that is wire level reentrant VIs. NI chose to implement OOP in dataflow ideology resulting in LVOOP. In traditional dataflow, wires carry only data. However in LVOOP wires carry also methods and functions. The problem is that in traditional dataflow each wire is totally unrelated to any other wire. In LVOOP wires may share same methods and functions as well.
This raises new kinds of problems. If on one wire a method is called, then all the other wires of the same type have to wait for this method to exit before they can call the same method. This problem can be solved by allowing dynamically dispatched methods to be reentrant in classical way.
The other problem is that shift registers and front panel values become global to the class. Sometimes this is a desired result but in may cases this defenitely is not what programmer wants. Traditional reentrancy would make shift registers and front panel values local to some node on block diagram. This may also be a wanted result, but in a dataflow thinking one may also want the shift register values and the front panel control values to flow with the wire. That is when ever wire is branched, also copy of each VI dataspace is created. This wire level reentrancy is totally new kind of reentracy for which there was no need before dataflow OOP. In this ideology the dataspaces of selected class methods would flow with the wire. Of course the compiler may choose not to copy the dataspace if it is not used or copy only those parts of the dataspace that may be modified elsewhere.
Please NI, pimp my next version of LabVIEW to include wire level reentrant methods.
--
Tomi Maila
Tomi Maila
