Force DLLs to tun in the same thread (expect the UI Thread)

[Steimers]

I've now build a action engine and that for itself seemed to work, all cases could share their variables. Then I tried to change with the threadconfig.vi  for "other 1" and "time critical" the setting to "1 Thread" and set the subvi (AE) to these setting. After I've done this the program chrashed, after I've made all setting with the threadconfig.ci back to default it still crashes.

So there must be a mistake or I've forgot something. Do you have an idea whose setting were wrong?

[Ben]

---

Steimers wrote:

...and "time critical" ...

---

Setting a VI to "Time Critical" will put it that same priority or above your mouse driver!

I only use that setting on a RT platform that has to close a loop deterministically and I KNOW will complete quickly.

Leave it as normal.

Ben

[Steimers]

Thank you, that fixed the problem (even if I don't know why the whole system chrashed I would expect that it's only getting really slow or something like this), now all my DLLs run in the same thread and in the same subVi what's over this another nice side effect of this Action Engine (really a thing that I will use more often up to now).

But now I have two questions that still need to be answered before I really can use it. 

1) How does a AE impact the other calculations/the rest of my program, does it need the same performancelike a solution where I build three DLLs (one before, one in, one after the "big while loop")?

2)And that's an important question, how can I handle it that "other 1" in the "normal mode" will be setto "one thread" if I build an executable/an installer with my codeand I can't do this settings with the threadconfig.vi by myself on a target machine?

[Andrey_Dmitriev]

---

Steimers wrote:

Using this library is no choice for me for a few reasons. I use a 64 bit system and this library only supports 32 bit systems, beside this the compute context they use there is way to complex for the things that I want to do and the disadvantage at this complexity is, that it's really hard to find out what exactly they do and you only hardly can find out of whose type their data structures there are.

I know that the key doing this must be the cuda context functions but I hoped to prevent the use of them by finding an other way because there are many open questions about how to use these things correctly and they are not documented very well how it seems. 

---

Glad to see that problem was solved and very sad that you have 64 bit system, but I would like to show how to use NI Compute Context for forcing call to the same thread, this not extremely complicated and may useful for someone else...

For using compute context at the first it should be initialized in DllMain:

 

Well, now I'll prepare two simple testers which will return back current thread ID. One (GetThreadID) will be called directly, and another one (GetThreadID_Single) - through simple wrapper:

 

As you can see above, declaration should be done with special macros (which depends from the amount of parameters) 

Now I will prepare three SubVIs:

One with DLL call in UI Thread:

Second in any thread: 

And finally one with using NI Compute (take a note - this DLL marked as thread safe):

Well, now I need simple VI which will show if DLL called in same thread or in different:

 

Results:

 

So, as you can see, now our DLL marked for call in any thread, but actually called always in the same thread, but not in UI thread.

Thanks for reading and best regards,

Andrey.

[Ben]

Steimers,

I do not understand you Q1.

For Q2 take a look at your LabVIEW.ini file and you will find a new key entry that will control the threads. Copy that line into the ini for your exe and you should be OK.

Andrey,

Thank you for that post! My approach accomplished the end via inuendo and gestures. Your solution actually controls the threading and alos appears to not need the threadconfig step.

Nice!

Ben