Multithreaded Vision Application

[Neville D]

Hi all,

I am working on a multi-threaded vision application on a PC with the latest Core 2 Duo processor. I have image data coming over two TCP sockets, and image processing using the IMAQ Vision libraries.

I have managed to parallelize the image processing, TCP communication, and display functions.

I have 2 Image processing loops, 2 TCP loops (one for each socket), a UI loop, and a display loop. Inter-loop communication is via 2 Q's and a few notifiers.

The image processing and TCP VI's are all re-entrant. The TCP and Image processing VI's are on different threads.

I tried playing around with changing priorities on the VI's but it made things a bit worse.

My questions are:

1 Are dll calls to the IMAQ dll's re-entrant? (probably not?)

2 Can these dll calls be made re-entrant? Would it make a difference?

3 Any way to set two different instances of the same re-entrant VI on the diagram on DIFFERENT threads?

3 Any other ways I can improve performance?

Thanks for any insights!

Neville

[Dan Press]

I'll try to answer those...

1 Are dll calls to the IMAQ dll's re-entrant? (probably not?)

A: They are thread-safe. You can tell because the call library node is yellow (as opposed to orange). Thread-safe = Reentrant in the call library node configuration. However, I noticed that many of the image processing VIs (such as

IMAQ Threshold) are not reentrant themselves. That doesn't seem right. Actually I have a parallel-ized IMAQ application, and I never checked that part before. I'll be opening up a service request on that one.

2 Can these dll calls be made re-entrant? Would it make a difference?

A: They already are. It is possible!

3 Any way to set two different instances of the same re-entrant VI on the diagram on DIFFERENT threads?

A: I believe so, just make sure those two different instances are not inside a loop. Doing that would cause a thread swap for at least one of them every time it is called.

4 Any otther ways to improve performance?

A: You can eek out some extra cycles by using UDP instead of TCP. Just make sure you build in some way to detect errors. For a reasonably short network hop, there is usually no big issue with packet loss.

[Neville D]

I'll try to answer those...

1 Are dll calls to the IMAQ dll's re-entrant? (probably not?)

A: They are thread-safe. You can tell because the call library node is yellow (as opposed to orange). Thread-safe = Reentrant in the call library node configuration. However, I noticed that many of the image processing VIs (such as

IMAQ Threshold) are not reentrant themselves. That doesn't seem right. Actually I have a parallel-ized IMAQ application, and I never checked that part before. I'll be opening up a service request on that one.

3 Any way to set two different instances of the same re-entrant VI on the diagram on DIFFERENT threads?

A: I believe so, just make sure those two different instances are not inside a loop. Doing that would cause a thread swap for at least one of them every time it is called.

Hi Dan,

thanks for the reply.

I checked IMAQ Threshold.vi and in Vision 8.2, it IS thread-safe. What version are you using? (8.2 is available as a download off the NI website, but might need SSP to activate it). There are some Window draw VI's which are obviously not re-entrant.. since they are UI related.

Getting back to putting two instances of a VI on a block diagram on different threads.. how do you do that?

The TCP part of the code seems to be quite fast.. I just write out about 30k of data in a single write and it takes 0 ms, so I will leave that alone.

thanks for the quick answers!

:beer:

Neville

[Rolf Kalbermatter]

I'll try to answer those...

1 Are dll calls to the IMAQ dll's re-entrant? (probably not?)

A: They are thread-safe. You can tell because the call library node is yellow (as opposed to orange). Thread-safe = Reentrant in the call library node configuration. However, I noticed that many of the image processing VIs (such as

IMAQ Threshold) are not reentrant themselves. That doesn't seem right. Actually I have a parallel-ized IMAQ application, and I never checked that part before. I'll be opening up a service request on that one.

While reentrancy is used here in both cases it is not exactly the same thing. Reentrancy for functions means just that they are basically protected from modifying parts that could collide if the same function is called again even before the first call has finished, including recursive calls.

Reentrancy for VIs is a bit more complicated. For a start it means the same as for functions but in order to do that LabVIEW does quite a bit of extra resource handling. And this resource handling is quite expensive. Making all your VIs reentrant without need can make the difference between an application that uses a few MB of memory and one that uses 100s MB of memory, without being faster and possibly even getting slower due to vast memory usage.

Reentrant VIs should only be made if a VI can have some lengthy operation that might actually wait (block on some external event or such) and should be able to be invoked multiple times in parallel. A VI that does execute fast or does not really idle in some ways for some time almost always will cause the performance of the application to be lower when it is set to reentrant execution.

Another use of reentrancy for VIs is the special case of uninitialized shift register maintaining instance specific data storage instead of the application global data storage for normal VIs.

Rolf Kalbermatter