Making LabVIEW multi-threaded, for independent parallel processes, connected by queues

[Ben]

Thank you very much for that well thought out answer Rolf!

While I do not expect you to be able to comment there was one more thought that came to me as I was reading your reply.

We used to be able to use Threadconfig to set how many threads were allocated to an "Execution System".

If the threads for "Other 1" were set to "1" and the wrapper was configured to use "Other 1"....

Again thank you for your time Rolf!

Ben

[rolfk]

---

@Ben wrote:

We used to be able to use Threadconfig to set how many threads were allocated to an "Execution System".

If the threads for "Other 1" were set to "1" and the wrapper was configured to use "Other 1"....

---

I was actually thinking about that solution while writing the response. But:

This would fail catastrophically if the same software was run on a LabVIEW system where this thread config hasn't been changed. That makes me generally not touch this at all, like a red glowing iron poke.

For a single isolated application it could be a last resort solution. For a VI library that is supposed to be used in multiple applications and/or by different users it is an absolute no-no! Even the reliance on proper serial dataflow dependency by wiring refnum and error clusters through is basically not a solution for any VI library that you intend to give to other people or reuse in the future for other applications. It's simply to easy to branch of these wires to do something in parallel to the rest of the application and there is a very good chance that even the original developer of such a library is going to somehow violate that when he comes back to the application to make a quick bug fix/improvement after some months or years.

[Ben]

I am bumping this thread because it has been so long since we heard an update, it will fall off of my recent ports list if I do not.

Any updates?

Still curious,

Ben

[Judith_ · Accepted solution]

Hi Ben,

yes, as of yesterday we found a solution that works for us. So, I installed the Desktop Execution Trace Toolkit to see which calls are being made to which thread and CPU. This looked quite complex, because many calls are being made (in a few seconds 30000). By inspecting from which thread a call is made and to which thread the function is returned we could see that many threads are being used. We could make our program run with the following conditions:

1) all VI executions systems to " same as caller". 
this way we don't restrict LabVIEW in which threads it can use.
2) all priorities to "normal". this way the scheduler does not have any restrictions.
3) we made an important change in our programming. Instead of copying 1 in N buffer to LabVIEW, we now copy buffers as long as the DMAbufferCount is smaller than 17 (it total there are 64 DMAbuffers). (The DMA buffers are the buffers in the RAM that the Alazar board streams the data to, and from the DMA buffers data can be copied to buffers of LabVIEW.) In practice this means that the DMAbufferCount always varies between 20 and 40, but this is great since it does not overflow any more (which made the data acquisition fail.) Now that our program doesn't crash any more, we could do some diagnostics on how many buffers it is copying to LabVIEW. If we don't do any processing on average 1 in 15 buffers is copied to LabVIEW, corresponding to a data copy rate of ~ 150MB/s. When we add some needed processing our program can handle about 70 MB/s data copy rate. 
We can see that all cores of our system are being used. (including hyperthreading). So we are pushing our system to the limit. Furthermore I would recommend anyone to keep the VI execution systems to "same as caller" and the priority settings to "normal". And it helps to put processes you want to run independently in separate while loops.

Thank you everyone for your help!
Best Regards,

Judith

[Ben]

Thank you for the update Judith!

Your report reminds me of a poster my better-half had hanging in the computer room where she had her PDP-11/70.

Take care,

Ben

[Bob_Schor]

Yes!  I have a (small) number of PDP-11's, none of which have been turned on in a while.  Trying to remember if I have an 11/70 ...

Bob Schor

[Ben]

---

@Bob_Schor wrote:

Yes!  I have a (small) number of PDP-11's, none of which have been turned on in a while.  Trying to remember if I have an 11/70 ...

Bob Schor

---

PDP-11/70 required at least 3, 19" racks to house the CPU, memory and a minimal amount of I/O.

Spoiler

The 11/70 that my better half managed is what she calls her form of "computer dating". I met her after she had a RM-03 head crash on one drive and while working that fix I realized there were bad carrige and rails on a second. I worked through the night and got everything back up with zero data loss. Of course after that I made a point to schedule some "preventive maintenance" to make sure everything was optimal for her.

So the night prior to the first scheduled PM for her, I was awaken by the police knocking on my door to let me know the alarm in my car was going off and the battery was about to die. Scrambling, I got the car started to recharge the battery and decided I would charge the battery by driving to the office and then sleeping on the floor under my desk so that I could make the scheduled visit.

30 years latter, it was worth the extra effort!

Ben

[Judith_]

I love this story!

Take care!