For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings


Need to speed up your development?
Have a look at our:

Samples & Tools


Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Multithreaded BRepMesh::Mesh

Wayne Christopher's picture

I am trying to triangulate a large number of faces using multiple threads. I'm seeing exceptions and segfaults in various places, such as GeomAdaptor_Surface::Load and BRepAdaptor_Surface::Initialize. I have called Standard::SetReentrant(true) and set MMGT_OPT=0.

Has anybody else used BRepMesh in a multithreaded context? Would it matter if the faces share edges (i.e. does the face mesher touch the edge data structures?) What if some faces share the underlying TopoDS_TFace?


Wayne Christopher's picture

It seems that BRepClass3d_SolidClassifier has the same problem. I get exceptions here:


Is there a list of OC routines and classes that are known to be thread-safe?

Eugine's picture


Do you have HAVE_TBB flag enabled?

Best regards,

Eugine's picture

If it is enabled meshing is made in parallel mode. So you need not multithreading. I think multithreading in this case could produce errors.

Best regards,

Forum supervisor's picture

Dear Wayne,
Unfortunately OCCT is still not thread safe.
It has initial preparations for multi-threading especially introduced in 6.4 (thread safe memory management and accelerated triangulation algorithm due to using Intel® TBB). But it (algorithm) gives correct results only for canonical surfaces. The next OCCT release will have a lot of additional improvements from thread safety point of view. But for sure it is just the first steps and not the last. So, it is a long way ...

Wayne Christopher's picture

Thanks for the information. If I am doing ClassifyPoint on completely separate solids (i.e. no shared faces, edges, etc) would that be okay in multiple threads?

Roman Lygin's picture

Hi Wayne,

You might want to use Intel Parallel Inspector XE to check for threading errors in your code.
AFAIR, for completely isolated solids, BRepMesh should work right out of the box.
For other algorithms (including approximation) there are still race conditions in 6.5.1. I have submitted a few fixes to OCC and look forward to seeing them back as part of the OCC source tree in 6.5.x.


Timo's picture

Dear Forum supervisor,

would you call BRepMesh::Mesh in OCC 6.5.3 thread-save or do you know about any problems with it?

Kind regards,

Forum supervisor's picture

Dear Timo,
BRepMesh::Mesh in OCC 6.5.3 is not thread-safe for the moment.
We have progress in this area, but some problems still are presented.
I do hope that we will remove them in next releases (depending on our
technical capability and availability of resources).

Timo's picture

OK, thanks for the info.

Forum supervisor's picture

Dear Timo,
Dome additional technical details are below. I do hope it will be interesting for you.
Since release of 6.5.3, two issues affecting parallel execution of BRepMesh have been fixed:
- Long-known issue of possible data race in b-spline cache (Mantis issue #22939: the fix is integrated to Git master branch on 2012-05-04);
- Data race during update of polygonal representation of edges in BRepMesh (Mantis issue #22850: the fix is under testing and we hope it will be integrated during the next week).

For the moment we are not aware of other possible issues with parallel execution of BRepMesh.