Do I need to use a semaphore when reading/writing a functional global from reentrant VIs?

[Nickster]

I have a program that spawns multiple reentrant VIs running simultaneously.  These VIs write their status to a functional global.  The VI that monitors them periodically polls this global to check out how they're doing and takes action based on their collective status.  (BTW, I'll mention that this monitoring VI is NOT the parent that spawned the reentrants, just in case this might affect memory management as it pertains to my question.)

Anyway, 90% of the time, stuff goes off without a hitch.  However, once in a while the whole thing hangs.  I'm wondering if there's any chance that I've overlooked something and that some kind of collision is occurring at the global.  If that's the case, then should I be setting a semaphore for the global read/writes?

And, if this is a problem, then there is something deep about functional globals that I don't yet understand.  My notion of them is that they should negate the need for a semaphore, since there is only one global instance, which cannot be simultaneously called by the various reentrants.  Indeed, this is arguably THE WHOLE POINT about functional globals, is it not?  Or am I missing something?

Thanks,

Nick 

[LuI]

I am not sure about the reason, but I would take a look at the execution settings (VI properties, category 'Execution'). AFAIK the default 'preferred execution system' is 'same as caller', which might, as you call your functional global from reentrant VIs, create at least more than one instance (as they might be called from different execution systems). I might be totally wrong here, but it costs you just a few klicks to check it out.

I's suggest putting this into a predefined execution system (for example 'other1'), which enforces the atomic execution of it for all callers. 

Just my € 0.02!

Greetings from Germany!
--
Uwe

[Nickster]

Thanks Uwe,

This is a good hunch.  However, functional globals typically run at "subroutine" priority.  With this priority, it is not possible to select a specific execution system; it is always "same as caller."

I will try your suggestion by switching to "time-critical" priority.  However, I do not know if this could lead to a different set of issues (non-determinism?).  It will probably take a little while to hear back from my guys on whether this makes a difference or not, because the error is sporadic, and sometimes doesn't come along for quite a while.

While probing all of this, I looked at the execution settings for my reentrant VI.  It has standard settings: "normal" priority, running in the "same as caller" execution system.  My impression has always been that LV creates the clones with unique names.  This allows the clones to be in the same execution system with no problem, and the fact that the execution dialog allows me to choose "same as caller" for a reentrant VI supports this assertion.  This is logical, since there could potentially be many more clones than available execution systems.  "Preallocate clone for each instance" is selected, which is what I want, I think, though I don't know if it matters in my application.

In summary, I am trying out your suggestion, but with skepticism.  Any other suggestions from anyone out there?  Any misunderstandings on my part that need clarification?

Thanks,

Nick