Are LabVIEW memory manager functions thread safe?

[banksey255]

Are any or all of the following LabVIEW memory manager functions thread safe?

DSNewPtr

MoveBlock

DSDisposePtr

Mainly I'm concerned about DSNewPtr, and whether making two calls simultaneously in different threads could return pointers to overlapping blocks of memory (it hasn't happened in tests so far, but I'd prefer to have assurance that it won't happen as this would cause unacceptable results). Also, in case I'm overlooking something, I also ask about the other two memory manager functions MoveBock and DSDisposePtr.

I ask as I've noticed that for loop iteration parallelism code that contains call library function nodes with "run in any thread" selected executes in a fraction of the time it takes when "run in UI thread" is selected, which would be very beneficial in my application.

Thanks!

[rolfk · Accepted solution]

Simply look at the extcode.h definitions in the cintools folder. Does it have a prefix of TH_REENTRANT then the LabVIEW developers determined that the function is thread safe and can be called in parallel from multiple threads.

Other possible prefixes are TH_SINGLE_UI, which only are allowed to be called from the UI execution system and TH_PROTECTED which means that it contains internally a mutex protection that prevents corruption of globals used in there, but which you might have to be careful about calling from multiple threads to avoid mutual exclusion locks.

And your observation is of course logical. Running a Call Library Node in the UI Execution System will not only force it to be executed in the single threaded UI system (effectively nullifying any attempted improvement through parallel loop execution as LabVIEW can't parallelize loops that contain an UI threaded object) but that call needs to also compete with other operations in LabVIEW that either are meant for updating its UI, but also might have been simply forced into the UI execution system to prevent non-reentrant issues.

That said, using memory manager functions in a tight loop meant to be parallelized is almost never a good idea. Trying to avoid memory (re)allocation in such code is definitely always preferable as memory management calls are a performance hog.

[banksey255]

Thanks, Rolf!

I opened extcode.h and indeed it has the TH_REENTRANT prefix for all functions I was interested in.

Stephen