LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Code Interface Nodes and multithreading (openMP)

Hi,

We are experiencing a rather strange problem with the use of Code Interface Nodes (CIN) in LabView. The CINs are built with the Intel Compiler in the Visual Studio .NET 2003 IDE and use the openMP directives to easily implement multithreading. This does not seem to give any problems, as long as we do not declare our code threadsafe. If the code is declared threadsafe, everything runs smoothly but LabView crashes when the VI where the CIN is located is closed. If we do not declare the code threadsafe, there is no problem but our user interface is blocked during execution of the CIN. Since we are building an application for other users this is not acceptable.

It clearly has to do with the multithreading, because forcing the compiler to create sequential code solves the problem. But off course we don't want to implement multithreading to disable it afterwards.

We could switch to DLLs, but we are building an exe version which is under full development and can be updated by our users through the internet. Since CINs are part of the exe file itself and DLLs are not, we would like to keep it this way.

We know this is a very specific problem, but we do not know if the problem is related to the multithreading in general or to the use of openMP in particular. Has anyone else tried multithreaded CINs and experienced any problems ? We basically just want to be able to stop the CIN from using our user interface, since we know everything is threadsafe.

Message Edited by Raistlin on 05-07-2005 07:34 AM

0 Kudos
Message 1 of 5
(3,022 Views)
Hi,

Please check the link below:

http://forums.ni.com/ni/board/message?board.id=170&message.id=35934&requireLogin=False

Are you running the CIN in the same thread as the User Interface? Have you tried to put the CIN into another thread. Put it in a subVI and change the Execution settings of the Vi to another thread.

Regards.

JV
0 Kudos
Message 2 of 5
(3,006 Views)
I have tried putting the vi in another execution system (standerd,other 1,other 2, ...) and the problem persists. I now built a DLL and have the same problem : marking it as reentrant makes the vi crash at closure, marking it as running in the UI does not give a problem. I now sent some code to Intel to check the thread safety, but I am quite certain there is no problem there.

I found another thread where the problem was mentioned but also without an answer that could get me any further :

http://forums.ni.com/ni/board/message?board.id=170&message.id=47264&requireLogin=False

Message Edited by Raistlin on 05-10-2005 02:04 AM

0 Kudos
Message 3 of 5
(2,995 Views)
Have you checked the tutorial about threadsafe CINs?

http://zone.ni.com/devzone/conceptd.nsf/webmain/a342b904a68811a0862567c9006bafed

Check if all the conditions for a threadsafe dll/CIN are correct.

Regards.

JV
0 Kudos
Message 4 of 5
(2,980 Views)
Thank you for your help.

It is not thread safe in the traditional way, since there is file i/o. But it does only run in one thread (the threading is done in C and only for the thread safe part of the program) and the tutorial also specifies that it can be declared thread safe in this case. It is also clear the problem lies with the multithreading, since compiling as sequential code does not pose a problem.
0 Kudos
Message 5 of 5
(2,969 Views)