liblvrtdark threading

[Tom Y]

I have a standalone application under Linux created by building a shared library from Labview and linking it with a C++ program. 

The Labview VI has two while loops that run in parallel.  They work fine in Labview and if I link my exported library against liblvrt.so, with execution switching between the loops regularly.  However, if I tick the "embedded runtime box" and link against liblvrtdark.so then execution starts in one loop, skips to the other after one iteration and then stays in the second loop for ever, despite various time delay VI calls (wait ms, wait until ms multiple, time delay) which are supposed to yield control of the CPU. 

Does the dark library support multi-threaded code?  The app spawns 10 threads, although only two actually seem to be active.  I'm using liblvrtdark.so.8.2.1.

Any ideas?

[Ian Colman]

Hi Tom,

The LabVIEW runtime engine 8.2.1 can support multithreading but it is not as optimised to do so as the 8.5 runtime engine. In 8.5 you may specify which core each loop executes using but in an 8.2.1 runtime engine this is not possible, the system will decide for you.

With regards to your problem with the loops, would it be possible for you to attach your code to a forum post then I can have a loop at it for you?

Regards,

Ian C.
Applications Engineer
National Instruments UK

[michhoefer]

Hi Ian,

this is not a problem of the version of the labview runtime engine. All version have this problem, including 8.5.
if you want that you application on linux runs without an active display you have to use the checkbox  "embedded runtime box" when you make the application.
Without choosing this checkbox everything runs fine.
For test you can use each programm with two loops.

best regards

michael

[Ian Colman]

Hi Tom,

After looking into this in gread detail for you I've asked my colegues in our HQ in the United States their opinions on the matter. I will let you know as soon as i hear from them.

Regards,

Ian
Applications Engineer
National Instruments UK

[Ian Colman]

Hi Tom,

R&D in the US have been able to recreate your problem so will be searching for a solution for you. It will likely be Tuesday before the next situation update.

Many thanks for your patience,

Ian

[Tom Y]

great, thanks for looking into this for us.

[Tom Y]

Any news on this?  I have just upgraded to Labview 8.5 and the threading performance in the standard runtime seems to have increased, my software is running really smoothly when in Labview itself.  But the performance of the compiled app using the dark runtime library is still poor.

Thanks for looking into this.

[Wiebe@CARYA]

You can also install a virtual X server. I'm no expert, but LabVIEW needs an
server, it doesn't need to be a real one.

Using a virtual X server or a VNC X Server, LabVIEW should be able to run
normally, without spilling the resources of a real X Server.

Regards,

Wiebe.

[Ian Colman]

Hi Tom,

I’ve just heard back from my colleagues in the US. It seems that the behaviour can be seen if six parallel while loops write to a separate file, but no problems are seen if six parallel while loops all writing to the same file. I’ve attached the VIs that were used to replicate your issue.

Unfortunately we don't know the root cause of this, though it seems likely that a permanent fix will require R&D development to fix this issue. Can I ask just how urgent the resolution of this problem is; as I’m afraid at the moment I can only advise a possible work around:

If you are seeing the issue through viewing output files, you may want to try paring your code down to the point where you only write to one file while leaving the rest of the code intact.  Since the dark runtime has no user interface, things like file I/O which by default run in the user interface thread may have trouble.  Another thing to try is to change the execution system of the top-level VI (File»VI Properties»Execution) from ‘Same as Caller’ to ‘User1’ (or anything besides User Interface).

Hope this Helps,

Ian

[Tom Y]

Thanks very much for looking into this, I will try changing the execution system settings. 

My application has to write to several files as well as communicating with three serial ports via VISA - sadly I cannot change this.  For the short term I am investigating using Xvfb (a virtual X11 server as suggested above - thanks very much!) - this will allow me to run the non-dark executable without actually running a full X11 system.  Hopefully this will give us a working solution for now, but it would be great if we didn't have to run this extra software. 

Good luck in identifying the problem!