The main limitation (that has bitten me the most often) is that functions that use the ui thread (property nodes and many call library nodes being to two most common), can block each other slowing down the system (but since LabVIEW is multithreaded this problem exists in a single core system but is less pronounced since it can't lead a to a core not doing work). But if you avoid property nodes where possible (especially in daq loops) and use defer panel updates if your changing a large amount you should be fine. You can set call library nodes to be reentrant to avoid running them in the ui thread (but be extremely careful to either add your own locking mechanism, or be absolutely sure that the call is really reentrant, very bad things can happen if your not careful with reentrant dll calls).
Note: I don't think DAQmx property nodes are run in the UI Thread but I'm not certain of that.
The one other "limitation" that comes to mind is that some race conditions (that are from improper code), may show up (or have an increased chance of showing up) in a multicore system.
A functional global can only be used by one thread at a time. So if two threads try to use the same functional global at the same time, the first to try will run and the second will wait (perhaps running other sections of code while waiting, note: this is what makes function globals safe) until the first is finished. Global variable reads will only see completely written variables (if that's you concern). But if you have more than one writer you could likely have race conditions (this will probably affect a single core system as well, and you should try to replace them with a functional global in that case). Shared variables are about the same as global but with some extra logic (and overhead) that can be used for handling various race conditions (guaranteeing one writer or adding buffering for readers), and they support communication between separate systems (the main reason to use them). Remember (in general) if things don't share a data dependency than they can run con currently.
Note: If you have have a lot of cores (4+) you may want to adjust the the system in threadconfig.vi
Matt W
