Tue, 09/13/2011 - 04:03
Forums:
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?
Thanks....
Tue, 09/13/2011 - 08:15
It seems that BRepClass3d_SolidClassifier has the same problem. I get exceptions here:
Standard_ConstructionError::Raise
Geom2d_TrimmedCurve::SetTrim
Geom2d_TrimmedCurve::Geom2d_TrimmedCurve
Geom2dAdaptor::MakeCurve
.........
BRepClass3d_SolidClassifier::BRepClass3d_SolidClassifier
Is there a list of OC routines and classes that are known to be thread-safe?
Tue, 09/13/2011 - 11:00
Hello,
Do you have HAVE_TBB flag enabled?
Best regards,
Eugine.
Tue, 09/13/2011 - 14:35
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,
Eugine.
Tue, 09/13/2011 - 17:03
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 ...
Regards
Tue, 09/13/2011 - 17:43
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?
Tue, 09/13/2011 - 20:46
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.
HTH,
Roman
Thu, 06/14/2012 - 20:37
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,
Timo
Fri, 06/15/2012 - 16:07
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).
Regards
Fri, 06/15/2012 - 16:52
OK, thanks for the info.
Mon, 06/18/2012 - 12:00
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.
Regards