Thread safety overview


is there any documentation available, which OpenCASCADE classes are

- not thread safe/not reentrant
- reentrant
- thread safe

I parallized some features of my app, to speed up my algorithms. Some algorithms are working, some not. I think, that some OpenCASCADE classes are not reentrant, so I am getting exceptions caused by multithreading and using these classes.

Laszlo Kudela's picture

Hello Thorsten,

I would also be interested in such a list, although I don't think there exists one already. According to my experience, for example BRepClass3d_SolidClassifier and GeomAPI_ProjectPointOnSurf cause problems when used in multithreaded environments.

I am wondering if it would be possible to run some thread error detector tool (e.g. Valgrind DRD) on the tests provided by OCC to identify such problems?


István Csanády's picture

The Geom_Curve/Geom_Surface subclasses are thread safe. Handles also thread safe. Others should not be considered thread safe. You should be able to run OCCT algorithms on different threads in different contexts (different objects), but methods on an object should not be called from different threads. OCCT developers make efforts to improve thread safety of OCCT (see:, but there are some issues under the hood, that can be really hard to reveal (like static variables). Many algorithms are parallelized by OCCT, like meshing and boolean operations.

Thorsten H's picture

I had always make copies of Geom_Curve/Geom_Surface instances, before multiple threads worked with theses objects. So I think, the classes Geom_Curve/Geom_Surface should be considered as not thread safe but reentrant..?

Is "GeomAPI_ProjectPointOnSurf" considered as an algorithm? If I didn't use critical sections around calls of this class, I was getting errors. So I think, "GeomAPI_ProjectPointOnSurf" is not thread safe nor reentrant..?

If the OCCT developers are working on thread safety, a list of thread safe/reentrant/not thread safe classes would be very helpful.

István Csanády's picture

1. Those are thread safe now. For example, the parallel meshing algorithm and boolean operations are evaluating those objects from different threads.
2. Yes, it is.
I think every algorithm should be reentrant, because it is hard to think of a reason why it shouldn't (static variables can cause problems usually, but those can be easily eliminated). If it is not, you should file a bugreport.

István Csanády's picture

Actually I wasn't precise: at least their evaluation is thread safe. Setting their parameters is not.