(How) are non-reentrant VIs queued ?

[Branta]

I have a single COM port that serves RS485 multidrop to 17 different items, various different parts (simultaneous loops) of my LabVIEW program want to talk to the various pieces of kit attached to the RS485 communications.  But as there is only one physical port at the PC, I used a single (continuously-running) VI to control it, any part of my program that wants to use the port puts a request into a Queue, then the port service VI performs the RS485 transaction and puts the reply data into a Notifier (the queued request had included a "requester ID" so that the RS485 service routine knows which notifier wants the reply).

And it all works beautifully, but ...

Since then I started using Functional Global Variables and so understand a lot more about the concept of reentrancy (or not).  I'm now wondering why I bothered with all the queues and notifiers !  If I just leave the (called from anywhere and everywhere) VI that performs RS485 transactions marked as non-reentrant, surely it would have been fine anyway, any part of my program that wants to use the port when it is in use will simply have to wait in (just about) the same way.

It occurs to me that maybe my use of queues is giving more predictability about the order in which requests are serviced, but so far I can't find any information about how multiple calls to a non-reentrant VI are serviced.  i.e. does the non-reentrant VI run for each "call" in the same order that the calls arrived, or does it have its own idea about priority where two or more extra calls are made whilst it is busy ?

Even this wonderful thread:
http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801?query.id=538785...
only shows me how the sub-vi is allocated in the near-trivial case where two concurrent processes want the same non-reentrant VI.

[Ben · Accepted solution]

LabVIEW utilizes the services of the OS system to do the scheduling.

Since I am not an NI developer I have no inside knowlege so the following is an admitted diplay of "hand waving" that those who know more should feel free to contradict (go ahead I dare you ).

When the AE is already executing and antoher thread want to execute that code, a mutex is checked and if busy, the clump of code is placed in a "resource Wait" state (at least that is what the used to call before the days of Windows).

Now the extreme hand waving starts...

That thread is then placed in the resource wait queue so when the resource is relased, then next element in the queue should get poped off the stack givne the mutex and then placed in the "compute queue" and is scheduld as the OS determines.

There are plenty of non-deterministic isues that enter into the game.

If thread 2 and 3 try to get at the Ae while thred 1 is using it, then it comes down to which of those two asked for the resource first that wil determine where they wind up in the resource wait queue.

Also acfter getting the mutex, the OS scheduler could (or at least it used) process threads out of order if it determines one thread has not be geting the attention it deserves.

So if the order of operations are importnat and you alredy had it figured using queues, then (brace yourself) you may want to go back to the queue version.

Not sure if I am saying want you want but I am giving a go.

Ben

[Ben]

If you are really interested in getting deaper you could set-up a set of VIs that hammer (in a loop no-waits) a single AE and use the Desktop Trace Excution Toolkit to get a good picture of what is happening.

If you do so, I would be very interested in the reports and what you find.

Your partner in wire,

Ben

[JÞB]

---

@Ben wrote:

LabVIEW utilizes the services of the OS system to do the scheduling.

 There are plenty of non-deterministic isues that enter into the game.

So if the order of operations are importnat and you alredy had it figured using queues, then (brace yourself) you may want to go back to the queue version.

Ben

---

Well stated Ben!

I would also chime in on another point that could cause some threads to "jump in line" and get processed out of order.  We rarely discuss execution systems or execution priority.  Yet these can also cause changes to the order request for resource queues are processed.

Suppose A.iv requests a blocked resource and has normal execution priority.  Also, before the resource is released, B.vi requests the resouce and has subroutine execution priority.  Ideally, the OS will service the higher priority threads first so I'ld expect B.iv to complete before A.vi.

Execution system is a bit trickier.  Assume the blocking vi runs with the prefered execution system of "Same as caller," wilt A.vi and B.vi having different prefered execution systems and the same execution priority.  The resourse queue will find the most effecient means of servicing the queue so order of execution MAY depend on which execution system the blocking vi is currently running in so that all requests in the same execution system are served first.

MORE HAND WAVING!~~~~

Of course, its called "Prefered execution system" so....  I assume the NI dev team had a reason to use the adverb prefered in the name. And maybe all queued requests execute in request order in the blocking vi's execution system. 

GREAT question! 

[Branta]

Many thanks for the very quick reply, that gives me a feeling for the issues (and I should have guessed the answer wasn't going to be real straightforward !).

It's no problem to stick with the queues, it's already working that way.

It occurs to me that somewhere down the line I might want to give priority to one of the "callers", and queues give me that option, either simply by using the facility to put something at the front of the queue, or else a more complicated prioritisation by examining the queue (pouring into another queue) and fishing out the priority items.  So I might be really glad I programmed it the hard way !

Thanks

[sree7891]

can you tell me how the RS485 multidrop communication. Actually i need to know how to write or read to each instruments using labview programming? 

[altenbach]

---

@sree7891 wrote:

can you tell me how the RS485 multidrop communication. Actually i need to know how to write or read to each instruments using labview programming? 

---

This has nothing to do with non-reentrand VIs and this 2 year old discussion thread, so please start a new thread. Thanks.