LabVIEW
Making LabVIEW multi-threaded, for independent parallel processes, connected by queues
Solved!
After reading the whole thread more or less completely, I"m still not quite sure what the problem of the ATSAPI is.
Their first response claimed that it was possible to call the library from (a) different thread but not multiple functions at the same time. Then they answer that their API can be called from other threads but that it is designed to make user side threading unneccessary.
The problem here is likely following:
For some reason they would want to guarantee that their APIs are all always called from the same user thread. In LabVIEW there is only really one thread configuration that is guaranteed to always use the same thread and that is the UI thread. But running something like an interface to a fast DMA bound data acquisition in the UI thread is of course like having a Ferrari and driving on a congested highway in the morning peak hour.
What they should really answer is:
- Can the APIs be called from different threads? This would clarify if they use so called Thread Locale Storage (TLS) as an intermediate storage location between different API calls. (Most likely that is the real reason for requiring the nodes to be configured in the UI thread).
- Or is it really like they claimed in their first answer that the APIs are thread safe but never can be called in parallel? That could be for instance the case if they use so called sessions (handles, refnums) that you have to pass from one API to the other and in which they store internal settings for that session. If access to those sessions is not protected, then it could be problematic if the API is called in parallel from multiple locations.
If the answer is the first then there is indeed a serious problem. A wrapper DLL could solve that by adding (another) handle to all API functions that would restore and save the TLS environment before calling the actual API. However this is heavy C programming stuff and not likely worth the effort. NI does have an example for their NVIDIA CUDA GPU Analysis Toolkit for writing your own extension DLL for that Toolkit. The NVIDIA CUDA API makes internally use of TLS and in order to not have to set the Call Library Nodes to run in the UI thread NI shows in those examples how to setup the TLS correctly so that the NVIDIA API always sees the correct TLS setup no matter from which LabVIEW thread the API is called.
If the answer is the second there are two possibilities:
Data flow in LabVIEW does prevent functions from running in parallel. If you are careful to never call two of those APIs in parallel by wiring them in such a way that they need to run sequentially, you already made sure that no API call can happen in parallel. For instance by wiring the session (handle or refnum) and the error cluster through each of them and then from there to the next VI, you already have guaranteed that the functions can not be called in parallel and would be able to change the Call Library Nodes to run in any thread. The downside of this is that YOU are now responsible for making sure that you wire the functions in that way. If you don't you can introduce errors that may not even happen for a long time, until you ship your application to the other side of the globe and suddenly it starts to misbehave in strange ways.
The other possibility is to create an Action Engine as what Ben suggested. If you don't set the Action Engine to be reentrant, it will block anyone from trying to run one of its methods while another method is busy. This is not the most elegant solution. AEs were great in the old days where no LabVIEW GOOP was available but I have since come to not rely on them that much anymore since they really set the OOP design principle on its head. They have only two advantages above LabVIEW GOOP nowadays:
1) They can wrap an API in such a way that it can be called from any thread in LabVIEW but guarantee that only one call into the API can be made at the same time.
2) They use significantly less VIs than any equivalent GOOP API, but this is mostly a moot point nowadays.
The AE takes extra time to create, makes handling your API potentially more cumbersome and the biggest drawback of AEs is that they tend to grow into monsters since the connector pane of the AE needs to accommodate any and all parameters from all the methods you want to wrap. The advantage to relying on proper sequencing through data flow wires is that you can not accidentally use the API in a way that violates the "don't call me in parallel ever" rule.
