VI Data Spaces and LVLIBP/PPL - creating a truly singular instance

[paul.r]

---

@Mark_Yedinak wrote:

---

@paul.r wrote:

---

@Mark_Yedinak wrote:

This is true. You would need to package your FGV into its own PPL and have all modules and PPLs use that single PPL with the FGV. To be honest, I would probably scrap the FGV and use a singleton class with a DVR to replace it. Again, this would be in its own PPL but a singleton class provides more functionality than a FGV.

---

How do you create a singleton class without a FGV? 
 

---

I didn't notice that the OP was trying to share information between an active application and the development environment at the same time. That will not work. The DVR or FGV will be in different memory spaces and thus will be different. In cases where I have had to share data between applications I use TCP based messaging to share the data. There is no other way. Based on the type of information that the OP is storing in the FGV, I would suggest that a configuration file is used which is read and then used by the application. This is relatively straightforward. You could use a common path to store the configuration file. The default application data folder on Windows (7 and above) is c:\Program Data. Create a subfolder there for your application and place the configuration file there. Both the development environment and the built application will be using the same config file.

As far as a class using a DVR without a FGV it is quite easy. The cluster of the class private data contains one or more DVRs to the actual private data. To instantiate the class you would use a Create method which would initialize the DVRs. The class wire will need to be passed through the code but all instances regardless of branches will be seeing the same data since everything is stored in DVRs. Copying the actual DVR reference is not a problem.

If you want to use the class without passing wires around then the class itself would have to use a FGV to get the DVR in order to access the data. In practise though, I generally don't do thing "wirelessly".

---

Using a class by reference isnt really a singleton - a singleton should guarantee that only one instance of the class exists. 

[Yamaeda]

If you want to share data between an .exe and the IDE the easiest is to use a file or the registry. That'd be a "truly singular instance".

/Y

[paul.r]

The root of the problem seeking to be solved isnt really sharing data between an .exe and the development environment - its trying to use the development environment to test new modules, while getting 'real' data from the built .exe. 

[Moray2000]

@Paul: exactly

File IO surely will work, but seems to me more like a beginners approach - a lot of wrapping around and maybe not really error proof when multiple instances want to write stuff at the same time.

i always read LV docs in that way, that: one vi on disk = one vi in memory when loaded - no other instances will be created. The behavior i see is more like classic program languages, which is kinda ok, but i didn't foresee that^^

Is there any hidden way to see other vi memory instances or maybe getting a reference to them?

[Mark_Yedinak]

---

@paul.r wrote:

Using a class by reference isnt really a singleton - a singleton should guarantee that only one instance of the class exists. 

---

You can guarantee it is a singleton by having the create check if the DVR is valid or not. If it is valid, do nothing because the object has already been instantiated. You can even include a flag in the private data for extra protection. Once created any further calls to the create method will simply return the same instance of the class. Yes, someone could drop a class constant on the block diagram but the class is useless without the call to the create method since the DVR is invalid.

[paul.r]

---

@Mark_Yedinak wrote:

---

@paul.r wrote:

Using a class by reference isnt really a singleton - a singleton should guarantee that only one instance of the class exists. 

---

You can guarantee it is a singleton by having the create check if the DVR is valid or not. If it is valid, do nothing because the object has already been instantiated. You can even include a flag in the private data for extra protection. Once created any further calls to the create method will simply return the same instance of the class. Yes, someone could drop a class constant on the block diagram but the class is useless without the call to the create method since the DVR is invalid.

---

So then the create method would need some sort of global variable to check the state of the DVR, right? Thats what I was getting at, I don't know any way to create a singleton without at least one global variable used.  

[Mark_Yedinak]

Another approach would be to build in some publish/subscribe network based messaging. Your exe would post messages with data updates. If no one is interested in receiving them at that point in time the message broker will simply drop the message. When you want to test new modules, your code would subscribe to receive the updates and then you would get the data. Yes, this adds complexity however it is also extremely flexible. The message broker can be used to broadcast the messages so you could have multiple recipients of the data. An approach like this would let you tap into the data any time you want. the producers of the data don't care if anyone is listening or not, they just fire off the update.

[Mark_Yedinak]

---

@paul.r wrote:

---

@Mark_Yedinak wrote:

---

@paul.r wrote:

Using a class by reference isnt really a singleton - a singleton should guarantee that only one instance of the class exists. 

---

You can guarantee it is a singleton by having the create check if the DVR is valid or not. If it is valid, do nothing because the object has already been instantiated. You can even include a flag in the private data for extra protection. Once created any further calls to the create method will simply return the same instance of the class. Yes, someone could drop a class constant on the block diagram but the class is useless without the call to the create method since the DVR is invalid.

---

So then the create method would need some sort of global variable to check the state of the DVR, right? Thats what I was getting at, I don't know any way to create a singleton without at least one global variable used.  

---

You don't have to have a global variable. A simple test of the DVR would let you know if it is valid or not. If the DVR is never obtained the reference is not valid and any attempt to access it would throw an error. If it is valid, the object has been instantiated and you have your singleton. Dropping a class constant on the block diagram and wiring it to any method would throw an error because the DVR on that wire would not be valid. ALL class data is stored in the DVR so without a valid reference you have an invalid instance of the class. The only way to get a valid DVR is by calling the create method. If you call create more than once it will only initialize the DVR on the first call because that would be the only time the DVR is invalid. Well, a call to the destroy method would clear the DVR and set it back to an invalid reference. However, if you call the destroy method you are disposing the object anyway so a call to create after that is creating a new instance.

[Moray2000]

with network based you mean sending everything via TCP/IP to the local loopback address? that sounds like a hack indeed^^

...Sorry for not getting it but what du you understand under network based?

[Mark_Yedinak]

---

@Moray2000 wrote:

with network based you mean sending everything via TCP/IP to the local loopback address? that sounds like a hack indeed^^

...Sorry for not getting it but what du you understand under network based?

---

No, you are not sending it to the loopback address. You would have a separate service running that is the message broker. When the application starts up it would connect to the message broker and send messages to it. If the service is not running the code which sends the messages would silently drop those messages. No message broker, drop the message. If the message broker is there it sends the messages.

Tasks that want to receive the data register with the message broker to receive specific messages. When the message broker receives a message from the producer, it will forward it to all the tasks that registered to receive it. If there are no tasks that registered to receive the message the broker just drops it.

This is hardly a hack. This is the basis for a distributed system and is a very powerful architecture.