GOOP methods and Reentrancy

[bbean]

I have an instrument class that uses serial comm to talk to a single instrument. Lets call it Instr. I created another class that has multiple instances of Instr. Lets call it Group. Each of the methods in Instr is duplicated in Group. I need to execute the methods for each Instr in the Group at roughly the same time in parallel.

Currently all the methods of instument are re-entrant (preallocate) and also some of the subvis like "serial packet send receive.vi", "wait for operation complete.vi",etc . The problem I'm seeing now is that there are hundreds of "serial packet send receive.vi" instances and lots of instances of the method vis.

None of the reentrant VIs maintain state so I'm going to try to switch to shared reentrancy and see if there are any improvements. But I was wondering, does shared reentrancy create a "pool" of instances where it only opens up as many as are needed for parallel execution at one point in time or does an instance get allocated every time the VI is executed.

For instance, say in my Instr class i have a method called "eject" (set as reentrant shared) and in the Group "eject" method the vi executes 8 instrument "ejects" in parallel. If i also call the Group "eject" in multiple places is:

# of Inst "eject" instances = 8

or

# of Inst "eject" instances = n x Group "eject"s x 8

Is there a better way to do this. I really only need one "serial packet send receive.vi" per Instr since all communication is executed serially. One thought I had was to open a reference to the "serial packet send receive.vi" and store the reference in the class, then just call this referenced VI every time. The other thought i had would be to move all of the method executions into the process vi for the class.

thanks for any help.

[jgcode]

None of the reentrant VIs maintain state so I'm going to try to switch to shared reentrancy and see if there are any improvements. But I was wondering, does shared reentrancy create a "pool" of instances where it only opens up as many as are needed for parallel execution at one point in time or does an instance get allocated every time the VI is executed.

Hi bbean

Preallocated Re-entrant VIs will maintain their state not Shared Re-entrant VIs. I.e. for each Preallocated re-entrant VI you place on the block diagram, each will have it's own state.

If you want to share the state of a VI in multiple locations on the BD then it cannot be re-entrant and you will end up with a Functional Global VI (FGV) type VI.

I am pretty sure you are right for your description of shared instances - a pool is maintained and as the need arises LabVIEW manages the pool and distributes from the pool meaning that VIs cannot maintain their state. This leads to less overhead - not every instance has to be in memory at the one time, but you will experience some jitter e.g. which may be important when used on Real Time systems.

[Aristos Queue]

. But I was wondering, does shared reentrancy create a "pool" of instances where it only opens up as many as are needed for parallel execution at one point in time or does an instance get allocated every time the VI is executed.

The pool will grow if the need for more parallelism arises. In other words, if a thread requests an instance and all are in use, another will be allocated. It's a standard "grow by double until threshold then grow by threshold increments" algorithm -- so you start with one instance in the pool. The first time the pool grows, it doubles to 2, then 4, then 8 and so on until some threshold... in this case I think it is 32, but I'm honestly not sure... at which point each request increases the pool by the threshold amount, which, again, I think is 32.