Generally, when is mutex required?

[Mike Seibel]

I am using the VI Server to launch multiple, identical .vit's in top level subpanels. It seems to be working fine.

However, I have been reading up on re-entrancy, Semaphores, LabView threading, etc. and am now adequately petrified there is a potential for disaster here if I am not careful.

Are there some simple guidelines for when to protect shared objects from concurrent access and when not to worry about it? It gets confusing when multiple identical VI's are running. I have not made them re-entrant, but they are obviously running concurrently. I am guessing that since they were created from a .vit they are technically differently named VIs, right? What surprises me is that a common sub-VIs called by the .vits also runs concur
rently...... and this is a normal VI (not re-entrant).

I gather from reading that in some cases (such as when a DLL call is involved) that some inherent protection is provided and I do not have to worry about it. Do I need to open the diagrams of all subvi's called in order to assess this threat or not?

Other cases (such as a VI that Reads-Modifies-Writes a global variable) concern me. In this specific case, the ReadModWrite.vi is called as a sub-vi from the vit's -- do I need to be concerned with protecting the global with a mutex (semaphore)? How about if the read/mod/write were separated into 3 different sub-VIs (hypothetically)?

If I make sure that anything "critical"(Globals R/Mod/W, GPIB Write/Query, etc) is accessed from a VI that is non-reentrant, then does that solve the problem?

I apologize for the shotgun question, but this issue really does affect many aspects of LabView.

[Ben]

Great question Mike!

A mutex is required when ever you have a data structure that can be modified by more than one entity.

That is the short answer.

These mutexes do not have to be explicit! LV uses mutexes "behind the scenes" to ensure non-re-entrant VI's are not executing at the same time.

So if I understand your "such as a VI that Reads-Modifies-Writes a global variable" as a VI that shared by all of your VIT's that is the one and only method used to modify the global, then your global data is being protected by the mutex that protect the VI!

This is one of the benefits that come along with the "functional global".

RE: the dll calls.

The call library function will default to the user interface thread. The user interfacte thread is single threaded so this ensures there is only one call to to the dll at a time. If you re-configure the nodes then this does not apply.

You can combine the two above thoughts to be able to run a dll in a thread other than the user interface and still ensure only one call at a time. You put the dll call in a non-re-entrant VI. This will harness that same feature to ensure the is only one caller of the dll while allowing it to run in a thread other than the user interface.

So...
Most of the time I can get away without using mutexes (mutexi?) becuase I make extensive use of functional globals.

Now let me share how I architect LV app's and convince myself that I do run into the issues you have raised.

LV uses the data flow paradym so I design my aap's around the data, rather than around the process.

I will start defining my data objects based on the app's requirements.

These data objects can be globals, files, registers, GUI objects, etc. When I have the ability to define these objects (i.e. I can not define device status and control register formats) I will use techniques similar to what is used in DB design, keeping data grouped logicly while keeping LV performance in mind as I go (i.e. If I know I will be accessing an array of clusters based on one of the elements, I will copy that element off to a seperate array to facilitate quick searches, like a "key").

Once I have the data structures defined, I will then go through and design the code that will provide the functionality I need and take carefull note of who write the data objects and when.

It is durring this phase of the design that alarms will go off when I see that data needs to be modified from more than one place.

Each of the alarms are dealt with in turn and the conflicts are handled using the tools that come with LV (LV2 globals, queues, semaphores, etc).

So by the time I start coding I already know where my conflicts are and have plans in place to handle each.

I would be interested in hearing how others approach design.

LV is a unique dev environment that requires design techniques that are unique from other environments.

I hope this answers your question.

Ben

[Mike Seibel]

Excellent answer -- thank you.

[Ben]

You are very welcome!

Ben

[DD]

I'm surprised that you say the non-reentrant sub-VIs are running
concurrently. Normally, I would expect that such only one copy of such VIs
would exist in memory, and calling VIs would be queued to call the sub-VI.

"Mike Seibel" wrote in message
news:506500000008000000DD000100-1.079395200000@exchange.ni.com...

> . . .Are there some simple guidelines for when to protect shared objects
> from concurrent access and when not to worry about it? It gets
> confusing when multiple identical VI's are running. I have not made
> them re-entrant, but they are obviously running concurrently. I am
> guessing that since they were created from a .vit they are technically
> differently named VIs, right? What surprises me is that a common
> sub-VIs called by the .vits
also runs concurrently...... and this is a
> normal VI (not re-entrant). . .

[Mike Seibel]

You are correct. Since posting the original message, I found that the non-reentrant sub-vi's are, in fact, queued. It was difficult to tell from outward signs, but I began questioning this too and added some debug to confirm it.