LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using Common VI's in Parallel Threads


I have an application which calls two independently running VI's from a main VI.  The three VI's communicate via queue's.  I have a command and data queue for each VI where the command queue uses a typedef ring control and the data queue sends flattened data structures as strings.  I have created different sets of command and data queues to avoid conflicts but I have used the same VI to send commands, ie the VI "Send Command" could be called simultaneously from any of the three running VI's to place commands on the different command queues.   Does this invoke the same VI as reentrant code or does this method invoke copies of the same VI?  I am getting some strange results where one of the VI's does not process its commands correctly.  Thanks.
Message 1 of 7
(3,397 Views)
If you've made "send command" VI as a reentrant VI (VI properties>>Execution>> reentrant execution), there will be seperate copies of data if simultanous executions arise. so you won't face conflicts in this way.
 
have you assigned different names to all 6 queues? Actually I didn't understand why you needed seperate queues for each VI.
Are you passing queues' references to "send command" as one of its input terminals?
 
 
Message 2 of 7
(3,380 Views)
I did not make "Send Command" reentrant.  I need six different queues because of the asynchronous nature of the data transfers between threads.  And yes I am passing queue references to the Send Command VI.  Since I did not make "Send Command" reentrant I am sure that is my problem.  Thanks.
Message 3 of 7
(3,378 Views)

Hi Davidwnypf,

      Just a warning on use of reentrant VIs.  1st, it shouldn't be necessary unless your "send-command" VI has some wait-state that would cause serial-executions to "stack-up".  In other words, if a call to "send command" should return instantly, it may not need to be reentrant.  If you choose to make "send-command" reentrant, and it buffers a "shift-register" value, of course you'll now have multiple independant buffers.  And, though nobody uses the dreaded "global" anymore, reading and writing to a global on the reentrant diagram is a sure recipie for headaches.

Cheers.
When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 4 of 7
(3,365 Views)
Well, you need to analyse the purpose of the vi. If the candidate only transforms the data into a string, and the queues will not hang because they have finite depth, then the vi will complete in machine time. If some of the queues have finite depth, and they are full, then the queue push will block further calls if the timeout is set to -1; here, reentrancy will help, at the expense of larger code size (as I understandit). I have found only one case where a reentrant vi was useful: checking the lock on a resource, I know there are others.
Message 5 of 7
(3,351 Views)
Odd_Modem's point is noted (...and appreciated, prompted this deNIzen to review some code that's presently in use.)
When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 6 of 7
(3,339 Views)

Davidwnypf,

If your concern is that LabVIEW will use the same data space for the duplicate VI you need not worry. LabVIEW automatically handles the necessary setup of a separate data space for each separate instance of the VI. So if you have the same VI in several places you will not have interfering data.

Respectfully,
-Ron
0 Kudos
Message 7 of 7
(3,316 Views)