Is glu thread safe?

OpenGL OpenGL: Advanced Coding
1

Hi,
I am using IRIX SGI in a multi-threaded/pipe environment, and have problems with gluNurbs calls. gluEndSurface() is apparently calling malloc(), which results in a crash. I was under the impression that both malloc() and the glu calls should be thread safe?

t_splay(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“malloc.c”:861]
t_delete(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“malloc.c”:796]
realfree(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“malloc.c”:531]
__malloc(0x178, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“malloc.c”:297]
_malloc(0x178, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“malloc.c”:186]
bezierPatchMeshInsertUV(0x102d0c30, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“bezierPatchMesh.cxx”:262]
OpenGLSurfaceEvaluator::coord2f(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“glsurfeval.cxx”:1098]
OpenGLSurfaceEvaluator::newtmeshvert(0x10302058, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“glsurfeval.cxx”:1161]
OpenGLSurfaceEvaluator::evalcoord2f(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“glsurfeval.cxx”:1031]
Backend::linevert(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“backend.cxx”:468]
Slicer::outline(0x10300ac8, 0x102d66f8, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“slicer.cxx”:1256]
Subdivider::outline(0x10300ac8, 0x1027b570, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:808]
Subdivider::samplingSplit(0x10300ac8, 0x1027b570, 0x1027b4d0, 0x6, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:464]
Subdivider::splitInT(0x10300ac8, 0x1027b570, 0x1, 0x1, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:433]
Subdivider::splitInT(0x10300ac8, 0x0, 0x0, 0x1, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:408]
Subdivider::splitInT(0x10300ac8, 0x1, 0x0, 0x2, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:407]
Subdivider::splitInS(0x10300ac8, 0x1027b750, 0x1, 0x1, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:388]
Subdivider::splitInS(0x10300ac8, 0x0, 0x0, 0x1, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:377]
Subdivider::splitInS(0x10300ac8, 0x1, 0x0, 0x2, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:376]
Subdivider::subdivideInS(0x10300ac8, 0x103013d0, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:358]
Subdivider::drawSurfaces(0x10300ac8, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“subdivider.cxx”:339]
NurbsTessellator::do_endsurface(0x10300908, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“nurbstess.cxx”:275]
NurbsTessellator::endsurface(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“nurbsinterfac.cxx”:133]
gluEndSurface(0x10259578, 0x10323a48, 0x2054d34, 0x5539, 0x10254030, 0xb4, 0x2043014, 0x20) [“glinterface.cxx”:78]

Thanks in advance.

2

GLU isn’t thread safe, malloc is thread safe only if you link to the multithreaded c runtime.
GLU is a utility layer on top of gl, so if you’re using GLU in two threads you should be taking the same synchronisation precautions as if you were using gl calls in two threads…ie. critical section protect all the code between the makecurrent/makecurrent(null) (or whatever the irix equivalent is…I should know, but I’ve forgotten).

3

GLU isn’t thread safe, malloc is thread safe only if you link to the multithreaded c runtime.
GLU is a utility layer on top of gl, so if you’re using GLU in two threads you should be taking the same synchronisation precautions as if you were using gl calls in two threads…ie. critical section protect all the code between the makecurrent/makecurrent(null) (or whatever the irix equivalent is…I should know, but I’ve forgotten).

Thanks, but we are using a multi-pipe graphics library (such as CAVELib and OpenGL Multipipe SDK). These libraries are designed for the purpose of running unsyncronized gl-calls in multiple graphics threads, so it must mean that raw gl-calls are thread safe. Are you saying the glu calls are different?

Also, do you mean that a non-thread safe version of the C-library is linked by default on IRIX (or other UNIX platforms)? I find that hard to believe, although I know that with Win32, you must specifically link with a multithreaded version.

4

Sorry, I didn’t read your post carefully. You are of course right when you talk about executing gl-calls in different threads on the same gl-context (we have one gl-context per thread). However, the other questions are still valid.

5

right, I see what you’re asking. If glu uses any statics, then it’s not thread safe. There’s no such thing as a glu context, as far as I’m aware, so you’ll probably have to mutex your glu calls.