LabVIEW
Making Call library function to run in any thread
@rolfk wrote:Unless the different flow controllers are all connected over different IO ports, it makes no real sense to call the 48 functions in parallel.
Yes, we don't know the details, especially when we have some hardware behind it makes no sense to make unnecessary parallelization, agree.
By the way, I played a little bit with threading and here some interesting observations with this simple code snippet, which I would like to share with community:
1. At the first, by default immediately after launch, the LabVIEW will reserve amount of threads equal to amount of the logical processors, but not less than eight (for every execution system, of course).
Proof (I have 16 logical CPUs):
16 threads - 50 ms:
17 threads - 100 ms:
I also checked this on VM with different amount of CPUs. Amount of threads is always equal to amount of logical CPUs, but not less than 8 just after start.
2. Amount of the available threads can be decreased with threadconfig.vi Utility (and well below 8).
Proof:
I will put into LabVIEW.ini the lines:
ESys.StdNParallel=-1
ESys.Normal=4
which means "custom config" with 4 threads for Standard (this is exactly what threadconfig.vi doing)
Result - now I have 300ms for 24 parallel calls, which means 4 threads:
This working also in builded application - these INI entries above shall be placed into Application's ini file.
3. LabVIEW can dynamically increase amount of the threads up to 24 regardless from amount of CPUs or threading's settings in INI.
Here a little bit magic:
I will increase the dwMilliseconds time in Sleep function to 500 ms in running VI and whole time will be 500ms, means 24 threads was involved:
Then this amount of the threads will be kept until restart of LabVIEW.
The "edge time" is somewhere around 100 ms (and depends from initial amount of threads). Looks like some intelligence added by NI - if LabVIEW have recognized that some code executed slowly, then amount of threads dynamically increased step by step until reached 24 (if you will carefully increase sleep time, you will see this).
To be honest - I'm not sure if amount of threads was increased, or switch to other Execution system was performed, but looks like amount of threads.
4. Amount of available threads can be increased above 24
For example, with settings
ESys.StdNParallel=-1
ESys.Normal=48
I will be able to execute 48 parallel calls:
And this is the only way to go above 24 threads without using different execution systems like was described two comments above.
5. There is no limit virtually, if I would like to have 4096 parallel DLLs calls - no problem:
The for loop can do only 64 parallel calls and nested parallel loops caused some troubles, so I'll put 64 copies here:
put these lines into INI file
ESys.StdNParallel=-1
ESys.other1.Normal=4096
and
and works.
May be I'm wrong in some statements above. If so - please don't hesitate to drop comment in this thread.
The only opened points for me - how to obtain amount of available threads and current execution system (I mean not preferred) programmatically.
Just funny Friday's experiments, nothing more. May be will be interesting for someone.
For me its interesting because of this:
This is PC for my next project and I should get full power from all CPUs (some operations on images at 10K FPS).
Have a nice weekend,
Andrey.
Seriously. Insane objects indicate that something is really getting messed up very well. And that something is a bug in your software. Yes it could be a bug in your DLL, but the chance that it is a bug in how you call those DLLs is much much higher. And I don't mean calling it reentrant or not but badly configured parameters and/or insufficiently sized string and array buffers!
If it was simply the fact that the DLL is doing something that is not multithreading safe, it could result in the DLL behaving strangely, returning strange results or simply crashing, but the DLL should have no business of being able to corrupt LabVIEW memory. Unless you misconfigured the Call Library Nodes. There is no safety net and double floor here. LabVIEW has to believe what you tell it the DLL function needs and the DLL function only knows one thing, the calling contract that the DLL programmer designed. It has no idea who is calling it, why, and under what conditions. It simply does whatever it is programmed to do, no matter who calls it.
LabVIEW can still cause insane objects, although these became rare.
Updating type defs, while there are array constants using them in multiple frames in a case structure. This used to crash, but that's even more rare.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
LabVIEW can still cause insane objects, although these became rare.
Updating type defs, while there are array constants using them in multiple frames in a case structure. This used to crash, but that's even more rare.
Yes it can. Very very rarely nowadays! But assuming it has to do with the calling of external code, it clearly is related to memory corruption. Those Insane Instances are basically when LabVIEW runs across its internal data and recognizes an illogical value, for instance a length for an embedded data field that runs actually beyond the entire length of whole data object. That clearly is messed up somehow. And that can happen for a number of reasons, such as not properly bookkeeping all the embedded data fields in an internal object, overwriting some value by bad indexing, etc.
But the other possibility is external code trying to write to memory it has absolutely no business to try to even read from. And that can happen from bugs in the external code (simply badly indexing memory) or from a mismatch what the Call Library Node was told to pass to the DLL versus what the DLL expects. The most popular one is for instance a function that clearly states that a certain buffer needs to have x bytes or elements for the function to write into and the LabVIEW programmer felt that calling DLL functions is like any other LabVIEW functions and that DLL will allocate the necessary string or byte buffer on its own. But it won't, respectively if it does, you have even more work to do to make it work with LabVIEW, because that allocated memory is nothing LabVIEW can use directly without some extra diagram voodoo.
Of course the insane errors could be LabVIEWs fault, but my experience is that if something strange happens and there is external code involved, it is in 98% of the cases that external code, or the interface configuration in the Call Library Node to call that code, that is at fault. And I have likely worked the most with this kind of thing besides the NI people writing the LabVIEW bindings for DAQmx and their other drivers. So that percentage is most likely even higher for most others playing with Call Library Nodes. 😄
Yes, I've never seen LabVIEW induced insane objects crash when executing code. It usually crashes on opening diagrams, moving\deleting or highlighting diagram objects..
I think insane objects on the diagram show red in the heap peak, but it's probably a red herring.
