Why aren't most vi.lib VIs reentrant?

[Matt_W1]

What debugging tools don't work with (non shared) reentrant vi's? single stepping and data probes both work. Just open the clone by double click on the block diagram, on a runnable vi (in LV 8.5 at least and probably back down to 8.0). With shared and top level reentrant vi's you can use open vi reference and knowledge of how clones are named to open their front panels (which should grant you access to the block diagram with ctrl-e).

I also doubt that the scheduler is slowed down noticeable by reentrant VI's. I'd guess that the data copies (from splitting up data), non shared VI and IO contention, and cache misses are the real cause of slow downs. And those can sometimes avoided if your aware of them (you can potentially access more cpu cache with reentrant vi's, since each core has a separate amount). I'll have to make some tests cases when I have more time to confirm my suspicions though.

Matt W

[rolfk]

---

@matt W wrote:
What debugging tools don't work with (non shared) reentrant vi's? single stepping and data probes both work. Just open the clone by double click on the block diagram, on a runnable vi (in LV 8.5 at least and probably back down to 8.0). With shared and top level reentrant vi's you can use open vi reference and knowledge of how clones are named to open their front panels (which should grant you access to the block diagram with ctrl-e).

I also doubt that the scheduler is slowed down noticeable by reentrant VI's. I'd guess that the data copies (from splitting up data), non shared VI and IO contention, and cache misses are the real cause of slow downs. And those can sometimes avoided if your aware of them (you can potentially access more cpu cache with reentrant vi's, since each core has a separate amount). I'll have to make some tests cases when I have more time to confirm my suspicions though.

Matt W

---

That remark about debugging not working for reentrant VIs is for pre 8.0 versions of LabVIEW. Note the date of that post!

And it was only with 8.2.1 I believe that you actually easily could debug multiple reentrant instances of a VI when the clone concept was officially available and working.

Rolf Kalbermatter

Message Edited by rolfk on 01-15-2008 09:44 AM

[rolfk]

---

@Phamton wrote:
Hi Rolf,
   I can see the advantages of "Share clones between instances" but unfortunately I'm still using 7.1 right now.  I really do have multiple processors so I was wondering if you could expand on what you meant by being "very [cautious] how you program your code".  I've read the NI articles on multicore programming; are there any other general hints you might give?
   If it helps, in my case I'm trying to fit data from 2 data acquisition channels.  I do a little bit of preprocessing in LabView, such as scaling the data, performing averages, etc. and then use a DLL call to perform the actual fit.  Currently I can process one "point" from one channel in 6 ms.  My acquistion time is every 10 ms so I'm hoping with two processors I can fit two channels in <10 ms.

---

If you really want to have control over multiple cores in LabVIEW you need to get your hands at 8.5. While 8.0/8.2 improved considerably in internal support for multiple cores, 8.5 has some of the means to give control over these aspects to the LabVIEW programmer.

LabVIEW 7.1, while working on multicores gives you little or no control over how LabVIEW executes its code on them. It may work sometimes but usually you execute on one core only. There is very little you can do to influence that since the OS in itself only allows tweaking core affinity on a per process base not per thread, which LabVIEW by the way also utilises more in >= 8.0.

Rolf Kalbermatter