DLL Hogs User thread

[Barionics]

Dear All,

  I am calling a Cascon JTAG application from LabVIEW and using to to programme an FPGA. 

LabVIEW interfaces to Cascon by calling a set of DLLs via driver VIs supplied by Cascon.

The act of programming the FPGA takes a couple of minutes and the LabVIEW user interface is locked up for this time, even though the call comes from a consumer loop. 

I understand, from my research, that thread unsafe DLLs can be forced to run in the user thread.  Does anyone know how to switch this feature off so that the front panel doesn't lock up, bearing in mind that the frivers are from a reputable source? 

  Regards,

  Ian

[rolfk]

Switch off is not an option. The UI thread is a single thread and it exists exactly once and that's it.

The question is if your DLL requires to be run in the single threaded UI thread. That is a question only the DLL programmer can answer safely (if he even cares about that).

Changing the Call Library Node to run the function in any thread is an exercise you could try but it comes with a big caveat: While it may not crash your system it can have nasty side effects that can range from delayed crashes later on, to strange and unexplainable failures during execution of your function, or even random results.

You definitely want to make sure that you do not call other functions inside the DLL in parallel to this function while it is executing to be a little bit more on the safe side, but there is no guarantee. If the DLL somehow uses global resources like global variables or hardware IO (or God may safe you from this, Thread local storage across function calls) then you are in for a huge mess if you change the Call Library Node to run in any thread. And as already mentioned the only one who can tell you if such issues exist is the actual DLL programmer (and if you have a really awesome DLL documentation it may be explicitly stated in there, but such documentation is rare and far between as the programmer doesn't usually like to write it and the tech writer doing it doesn't have enough technical knowledge to care about such "minor" details).

[Yamaeda]

If you're using the Call Library function to use this DLL it's per default running in the UI thread and is an orange(?) node. If you r-click it you can change this to Run in any thread and it should turn yellow.

/Y

[Barionics]

Thanks for all of the above gents,

   I have discovered that there is a Cascon VI in the drivers which decides whether to use UI thread or any thread, but, of course, it is locked so I can't peek inside.  I tried bypassing it and forcing 'any thread'  but it led to a crash further down the line, as predicted.  Unless Cascon can be persudaed to make a fix it looks like I am stuck with the long pauses.   I can't even create a moving 'BUSY' sign to tell users that it hasn't locked up.  How tiresome!

[GerdW]

Hi Barionics,

---

@Barionics wrote:

I can't even create a moving 'BUSY' sign to tell users that it hasn't locked up.

---

You can split your one application into 2 separate apps: one just handling the user interface and another app handling that JTAG device. Have them communicate using network protocols. This way your UI will still be able to react to user actions while the other app is blocked by those DLL calls…

[Yamaeda]

---

@Barionics wrote:

Thanks for all of the above gents,

   I have discovered that there is a Cascon VI in the drivers which decides whether to use UI thread or any thread, but, of course, it is locked so I can't peek inside.  I tried bypassing it and forcing 'any thread'  but it led to a crash further down the line, as predicted.  Unless Cascon can be persudaed to make a fix it looks like I am stuck with the long pauses.   I can't even create a moving 'BUSY' sign to tell users that it hasn't locked up.  How tiresome!

---

You should be able to change the cursor to the Busy circle before calling the function.

/Y

[Barionics]

Thanks for your thoughts Gerd,

   I had thought of that but my error handler, which is launched asynchronously, works in a similar way and is also locked up.  It looks like LabVIEW has one UI thread for all apps, and possibly the rest of Windows too.  Or am I wrong in this? 

Ian

[Barionics]

Thanks for the idea,

   The cursor is already a busy circle so no problems there.

   Ian

[rolfk · Accepted solution]

---

@Barionics wrote:

Thanks for your thoughts Gerd,

   I had thought of that but my error handler, which is launched asynchronously, works in a similar way and is also locked up.  It looks like LabVIEW has one UI thread for all apps, and possibly the rest of Windows too.  Or am I wrong in this? 

---

That definitely sounds bogus! Are you sure you launch your error handler as a seperate LabVIEW executable? How do you communicate to it from your LabVIEW program? If it is a seperate process you would need some interprocess communication like TCP/IP, shared memory or file IO.in order to communicate between the two. If you just launch it as asynchronous VI it will of course run in the same process, which is easy to communicate to with queues, etc. but shares the same UI thread.

Seperate processes can’t share the same thread as they run in completely independent virtual memory spaces and if there could be such a sharing between two processes that would be a huge security problem in Windows.

[Barionics]

Thanks Rolfk,

        That sounds like a definite option, but I am going to back burner that as an option for the moment.  I have spoken to Goepel and it seems that there is an alternate set of DLLs which use an API client and should fix the problem. 

  Thanks for your help,

        Ian