NXOpen Is Not Thread-Safe: What Developers Learned the Hard Way

This is one of the most consequential architectural constraints for anyone building a real NXOpen application (as opposed to a one-off journal), and it is not spelled out prominently in the official API reference.

The core rule

According to discussion on the Siemens PLM/DISW Programming & Customization forum ("Threading" thread), the NXOpen toolkits are not thread-safe. You can spin up worker threads to do non-NX work (file I/O, network calls, computation), but every call into NXOpen must happen on the main thread. Calling NXOpen methods from a background thread produces exceptions or undefined behavior rather than a clean error every time.

Where this bites people in practice

• NX Remoting / client-server setups: a documented case on the Siemens community (remoting server/client connection thread) describes an "SM function called from the wrong thread" failure when a remoting client attempted to open a .prt file from a thread other than the one NXOpen expected. This was reported as fixed starting in NX 10.0.2 MP2 for that specific remoting scenario, but the general rule — keep NXOpen calls on the main/UI thread — still applies broadly.
• Long-running UI operations: developers who try to offload a long NXOpen computation to a background thread to keep a WinForms/WPF UI responsive run into the same wall. The forum answer to "Is there any NXOpen API for multithreading?" (community.sw.siemens.com) confirms there is no supported multithreading API for concurrent NXOpen calls — the pattern instead is to keep NXOpen work on the main thread and use Application.DoEvents()-style patterns or asynchronous non-NXOpen work (e.g., progress dialogs) around it, not true parallel NXOpen execution.

Practical takeaway

• Treat "NXOpen calls happen only on the main thread" as a hard architectural constraint from day one, not something to retrofit.
• If you need background work (downloading a file, calling a REST API, heavy non-NX computation), do that off-thread, then marshal the result back to the main thread before touching Session, Part, or any NXOpen object.
• If you're building a remoting/automation server that opens parts on behalf of remote clients, be extra careful about which thread the request handler runs on — this is a documented historical source of intermittent failures.