Architecture for concurrent access to shared resources

[YannickB]

Hello,

I'm currently looking for an architecture to use shared resources in multiple loops. 

Coming from java/c++ languages, I thought it would be simple : initialize the connection in a class, pass a reference into my multiples Vi's and use it.

For a concrete case: I'd like to connect to a mysql database and log alarms when they append, I would like a unique connection, shared between all my independent processes.

However after doing my first tests with my first class, I realized classes references don't exist in labview (NO, I don't see the hideous solution proposed in the example VI as a solution... and I wonder how they dared putting that as a "serious" example).

So I'm back to the pen and paper to find a nice solution.

One way I see is to have a separate loop to handle the connections and accesses and use a "linked" class (through a queue as one of the field of my class) for usage. However, I found a bit disappointing having to use a VI and a class. It would be so nice to have only one class that can be shared and easily used.

Is that way of programming simply impossible in labview (maybe I tend to cling to the way of programming I'm used to) ?

If it is, what kind of architecture should I use to have something similar ?

[AYanez · Accepted solution]

Hi Yannick, I have been looking for solutions to similar problems in recent time. Many LabVIEW users come (Myself included) from programming languages focused on references and LabVIEW is by value.

A possible solution to your problem is like you said a reference, but in LabVIEW is better using  a message oriented approach.

You can have as you said a module or VI with the connection to the database, now you need a communication mechanism to transfer data (Many to One direction) user events are very useful for this purpose.

You can create the reference in your Main VI and using a functional global variable to share the reference with other modules. In my opinion is better in term of security sharing a User Event reference that a Database connection reference because in the future other developers can use the API in bad way and finding the cause of issues would be harder.

Another solution that I have used for logging errors for example is a Singleton pattern, take a look in these slides: https://forums.ni.com/t5/Bay-Area-LabVIEW-User-Group/LabVIEW-Design-Patterns-Mini-Series-Singleton-b...

However thinking about flexibility could be better the message oriented solution because in the future is possible that you need to use the database for other stuff and with Singleton you should increase the methods in the class and Singleton only can point to 1 instance of the object.

I started with a reference approach but now step by step I am doing more message oriented programming and everything works ok 🙂

[paul.r]

You can always put a class in a DVR.. Is this what you are referring to as a hideous solution?

[Mark_Yedinak]

---

@paul.r wrote:

You can always put a class in a DVR.. Is this what you are referring to as a hideous solution?

---

Or put your class private data into a DVR and pass the class wire around. This is my prefered method since the dereferencing occurs inside the class methods.

[YannickB]

Thank you for you answer, this is exactly what I'm looking for !

for now I have used quite often FGV and queue/notifier. FGV are ok in term of functionality but I found them a bit odd in the way they work.

and queue/notifier are often my way to go but has the drawback to need a additional loop, which often makes the code less readable and easy to use in my opinion.

Although I use them a lot for input and output of my subsystems and in this case it works wonderfully with my subsystem describe by a class or a FGV.

The link you provided is exactly what I'm looking for ! I just need to get familiar with DVR as I have not used them yet.

Interesting that they seem to also find NI solution Ugly and unpractical.

I'll be considering to keep the separate loop and the helper class though. as you It might be more flexible.

Thank you !

[paul.r]

You can still do the de 

---

@Mark_Yedinak wrote:

---

@paul.r wrote:

You can always put a class in a DVR.. Is this what you are referring to as a hideous solution?

---

Or put your class private data into a DVR and pass the class wire around. This is my prefered method since the dereferencing occurs inside the class methods.

---

You can still do the dereferencing inside class methods when you wrap the whole class in DVR. In fact, if I intend for a class to be used by reference, usually the only public methods I expose are ones that take in the class reference - this makes it obvious the class is by reference, versus having some by reference data in the class private data. (I am currently working on an application where the prior developer put some by reference data in classes, and passes the classes around the application to share that by reference data/functionality, then has the classes being used by value in a main loop and it drives me insane.)