reading several STEP files in parallel - Forum Open Cascade Technology

Massimo Ferri
Mon, 02/24/2020 - 20:35

Forums:

Hello,

I'm writing an application which processes several STEP files. As soon as I try to read them in parallel (i.e. a STEPControl_Reader instance per thread), the application crashes. Digging into the callstack of STEPControl_Reader::ReadFile, I could see the crash occurs inside the "rec_newarg()" function. A quick look at that function showed it makes heavy use of static variables, which likely sounds as the main reason of the crash.

Am I doing something wrong? Is there any way to prevent/solve/workaround this problem? I apologize in case there exists already a similar topic but, at my surprise, I couldn't find any in the forum.

Massimo

Kirill Gavrilov
Fri, 02/28/2020 - 22:30

Unfortunately, STEP reader still uses a couple of global objects preventing its usage in concurrent threads, so that your issue is expected.
For now, you may perform concurrent translation from several STEP files only within several processes, not threads.

In case, if this is a blocking issue in your project, you may consider using Open Cascade commerical services for fixing this OCCT limitation sooner.

Massimo Ferri
Mon, 03/02/2020 - 11:56

Hello Kirill,

Thanks for your reply. An interesting fact I've noticed in my tests is the following: it looks like only the 'ReadFile' part is not thread safe, while I get no problems (not heavily tested, though) with 'TransferRoots' and 'OneShape', see rough snipped below. Is that safe? Or I'm just being lucky here?

STEPControl_Reader reader;
globalMutex.lock(); //assume globalMutex is a global variable, here
int status = reader.ReadFile("myFile.step");
globalMutex.unlock();
if( status != IFSelect_RetDone)
  throw std::runtime_error("reading step file failed ...");

reader.TransferRoots(); //looks like this is thread-safe
TopoDS_Shape shape = reader.OneShape(); //same here...
[...]

If that is safe, then the performance loss is highly mitigated, as in my tests (unfortunately, I can't share the step files I've been using) it results TransferRoots is actually the heaviest part, by far.

Kirill Gavrilov
Mon, 03/02/2020 - 22:19

I don't think that TransferRoots() step does not use global objects, so I wouldn't rely on this assumption without intensive testing or looking into code. From my understanding, this step alos uses global working session, and hense, not thread-safe, even if it looks like this in small tests.

OneShape() just returns result after translation, so that it is not affected by this issue.