Question about Implicit Multithreading

[wiebe@CARYA]

---

@Petru_Tarabuta wrote:

But my question was broader:

---

I know, I just wanted to rebuke that the 0 wait (ms) is a bug.

---

@Petru_Tarabuta wrote:

why is the "trick" of using a 0 ms wait needed in the first place? The way LabVIEW is taught in the Core 1 and Core 2 courses suggests that reentrant VIs would execute in parallel as much as possible. In other words, that LabVIEW would use n threads if there are n logical cores and at least n chunks of code that can run in parallel.

---

AFAIC, The trick shouldn't be needed.

It isn't needed in LV16, and not in any version I've ever used.

If it is needed in LV23Q3, it looks like something fell over, and it needs to be fixed.

[Darren]

I've let LabVIEW R&D know about this thread so the issue can be investigated.

[James_McN]

If it adds anything, I've replicated this in 2023 Q1.

Using Process Explorer I can see that without inlining only 1 thread is getting loaded but when I add inlining then 6 threads show under load. This is on a VM with 6 virtual cores (no idea why I picked 6 when I built it!)

[mcduff]

Here's another twist, at least for LabVIEW 2020.

When I run main0 like below with proc0 set to Preallocated Clone with no wait function, I get the serial execution seen earlier.

However, not changing anything in proc0 and running it in a Parallel For Loop,see below, I get parallel execution. Explicitly calling a parallel loop I guess makes threads for it, even without a wait function.

[Darren · Accepted solution]

LabVIEW R&D investigated this issue and determined that this was a bug introduced in LabVIEW 2019. I have filed Bug 2558611 on the issue. The suggested workaround, as y'all have already determined in this thread, is to use a 0 second Wait (ms) call in any For Loop, While Loop, or multi-frame sequence structure that exhibits the behavior.

[IlluminatedG]

2019?! Wow I was not expecting that.

[Darren]

Neither was anyone else…

[wiebe@CARYA]

---

@Petru_Tarabuta wrote:

Thanks again for the replies.

---

And kudos (well, at least 3 from me 😁) for bringing this up!

[Petru_Tarabuta]

Thanks, Darren, for forwarding this to the R&D team. It's impressive and satisfying how quickly they were able to pinpoint the issue.

It would be useful if there was a white paper that explained in detail the algorithm or heuristics that LabVIEW uses to implement implicit multithreading. (sorry if one exists already)

The white paper could explain the general design decisions behind implicit multithreading, but also address more detailed questions such as:

• Does multithreading behaviour depend on LabVIEW bitness?
• Does multithreading behaviour depend on OS (Windows, Linux, Mac) and/or on OS bitness?
• Does multithreading behaviour depend on Shared Clone versus Preallocated Clone?
• Does multithreading behaviour depend on Inlining being enabled or disabled?
• Does multithreading behaviour depend on LabVIEW version (differences/improvements from year-to-year)?
• Any special considerations when there are a very large number of chunks that can run in parallel (e.g. 1,000 potentially parallel chunks on an 8-core machine)?
• Any special considerations when the OS is busy  (e.g. more than 50% CPU usage taken up by apps other than LabVIEW)?
• Any special considerations on RT?
• How and when to use 0 ms wait's to tailor/optimise multithreading.

Thanks!

[wiebe@CARYA]

---

@Petru_Tarabuta wrote:

The white paper could explain the general design decisions behind implicit multithreading, but also address more detailed questions such as:

---

Pretty sure the answer to most (all but the the last) of these questions is:

no, it just works. 🤗

If this bug wasn't there it would just work...