As IlluminatedG pointed out, in LabVIEW classes are at some level just fancy clusters with data and inheritance rules attached to them. There's a write up from NI on why they made some of these decisions that is worth reading. That having been said... LabVIEW classes being passed by value instead of reference does make some things a bit hazy.
I assume that the jist of your question is that you have a single object that you wish multiple asynchronous threads to be able to act on? If that is the case, there are certainly problems with an action engine.
- If you read your object from your AE, it is passed by value. This means that if you read your object and then update it's private data, you will have to write back to your AE before it is reflected.
- Using an AE in this manner isn't really any safer than a global variable. You still could run into race conditions because you're just writing the value. If you incorporate all class functionality into the AE to avoid possible race conditions, you don't really have the benefit of OOP.
The answer I want to give is "well, just refactor your program so that you don't need to do this". I have often slung objects around through queues or notifiers where I expect and understand that I'm passing by value, not by reference. Whatever asynchronous process needs to modify that object will do so and then pass it on to the next process or location that is expecting it. In fact, this is basically how the actor framework works!
However, sometimes you're too far into a project to realistically refactor, or there are cases where you really do want one object being acted on by multiple threads (a heartbeat monitor for example). In this case, it is possible to store the object inside of a Data Value Reference (DVR). I've done a few different takes on this over the years, but you can get the basics in this article.
Hopefully this helps
