Understanding behavior of an FGV in AF

[ChrisStrykesAgain]

I'm pulling what's left of my hair out trying to figure out something that should be obvious. (Before we go too far, I realize there are better ways of doing this. I will probably use one of them. I'd still like to figure out what I'm doing wrong.) I'm relatively confident I have a key misunderstanding of some AF principle here, but I can't figure out what it would be.

I have an error handler actor based on an FGV that keeps my file reference open. Every other actor in my project inherits from it. Pre Launch Init calls it with a "register" argument, Handle Error calls it with a "log" argument, and Stop  Core calls it with de-register. I avoid duplicate file references by implementing ref-counting within the DVR.

Now, the refcounting seems to work great. The problem I'm seeing is that when I deregister, my file reference validity isn't consistent. Given the following FGV:

Sometimes the reference is invalid at (2). Other times the reference is good at (2) but invalid at (7). As pictured, it's valid all the way through. This is all with the same functional code, just changes in where indicators are placed and what is probed. It seems like a clear race condition.

I can imagine a scenario where it would be invalid at (2) if the FGV went out of memory or something of that nature, but what I can't figure out is how it would go bad after the Write to File but before the Close, given that this is a non-reentrant VI. Any thoughts?

I've attached a sample project for inspection, if that's helpful.

[drjdpowell · Accepted solution]

References in LabVIEW have lifetimes tied to the top-level VI under which they are created.  Each Async-Called VI is a separate top-level VI, so the first Actor that called your FGV effectively "owns" your file reference.  When it goes idle, your File ref is invalidated, even if your FGV is only part-way through using it. 

[ChrisStrykesAgain]

I guess that would explain it. Thanks!

Thinking asynchronously is hard. 😞

[FabiolaDelaCueva]

By the way, this is one of the reasons DQMH modules own the creation of their own event references. We keep the event references in an FGV and if we want to ensure the references are valid for the lifetime of the DQMH module, having the module create them ensures that.

[Taggart]

That is also why in AF, the actor creates and owns it's own queue