thread safe

Hi all,
Is occ thread safe? Is it possible to work on constant objects in several working threads? (For example making different sections out of a solid). Our application crashes. I think there might be problems with the memory management.

Thanks.

Stephane Routelous's picture

Hi,

I'm not sure, but I think it is not thread safe.
You could enclose the OCC calls to make them thread safe, and check if it works.

Stephane

andi's picture

Already tried enclosing them in critical sections (for example). This works but this way you lose the advantage of parallel work. All blocks of code working with OpenCascade objects must be enclosed within the same critical section, otherwise you get an crash sooner or later.

helloha's picture

Quote:"All blocks of code working with OpenCascade objects must be enclosed within the same critical section"
I wrote the read step function(using XDE way). It works fine when i read step file individually. when i call read step function for several times, after 50 times, it crashs. I don't know what it means by "OCC objects must be enclosed within the same critical section". My first question is how do know whether those objects are in the same critical section. I don't really understand what it means by "critical section"
Furthermore, does it mean using "Standard_mutex.hxx>?
it would be great if you could give me a psuedo code on enclosing all OCC objects in the same critical seciton. if it's related to using mutex, can you give me examples on before creating which object to put mutex.lock() and where I should use mutex.unlock()?
thanks
winthan

helloha's picture

here goes my code.
how to enclose and differentiate whether they are in the same critical section?
#include
STEPCAFControl_Reader* reader=NULL;
try{
try{
OCC_CATCH_SIGNALS;

if (g_cs==NULL)
{
g_cs=new CRITICAL_SECTION;
InitializeCriticalSection(g_cs);
}
EnterCriticalSection(g_cs);
log << "read step: entered critical session..." << endl;
Standard_Integer red=0;
Standard_Integer green=0;
Standard_Integer blue=0;
//themutex1.Lock();
Handle(TDocStd_Document) Doc;
Handle(XCAFDoc_ShapeTool) Assembly;
//themutex1.Unlock();
XCAFApp_Application::GetApplication()->NewDocument("MDTV-XCAF",Doc);
Assembly = XCAFDoc_DocumentTool::ShapeTool(Doc->Main());

/////////////end
the way that i use critical section is in the following.
////////////

/////////////

* Sample C/C++, Windows, link to kernel32.dll */
#include
CRITICAL_SECTION cs; /* This is the critical section object -- once initialized, it cannot
be moved in memory */

/* Initialize the critical section -- This must be done before locking */
InitializeCriticalSection(&cs);

/* Enter the critical section -- other threads are locked out */
EnterCriticalSection(&cs);

/* Do some thread-safe processing! */

/* Leave the critical section -- other threads can now EnterCriticalSection() */
LeaveCriticalSection(&cs);

/* Release system object when all finished -- usually at the end of the cleanup code */
DeleteCriticalSection(&cs);

//////////

////////

should i create new critical section whenever i create new object like Brepmesh or etc.?
thanks
winthan

guillen's picture

Hi,

I have an engine write in C++ using OpenCascade. My Gui is written in Java. If I want thread safe, do you mean that each time I call OCC (through JNI) I must put this call in a Critical Section? What will happened if the event thread of java need to access to OCC for any reason (repaint, ...) The event thread will wait???
Thanks a lot.

Mikael Aronsson's picture

If all your code is called from java you might as well use java synchronization instead, easier to use.