OpenGL & multithreading

[mjaz]

Hi OpenGLers,
I need to have uninterrupted display (with no drop) of frames for a psychophysical experiment. For that purpose, I need to spawn a thread dedicated to the display (and redisplay) of my screen. I know how to set the policy of and create and parameterize a new thread. My OpenGL code is also up and running (when I do not use multithreading). Can someone help me tell me (or preferrably give me an outline code) for how to make my OpenGL display function a thread.

I have tried to pass the pointer to my thread to the glutDisplayFunc() and glutIdleFunc(). It works but there are some minor problems (e.g. the program instead of going to the glutMainLoop(), exits after the first round of display.

Here is a simplified version of my main()

int main(int argc, char **argv)
{
pthread_t p_th;
pthread_attr_t pth_att;
int status;

if ( (status=pthread_attr_init(&pth_att)) != 0 )
exit(1);
if ( (status=pthread_attr_setdetachstate(&pth_att, PTHREAD_CREATE_DETACHED)) != 0 )
exit(2);
if ( (status=pthread_create(&p_th, &pth_att, pth_main, NULL)) != 0 )
exit(3);

glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DOUBLE);
glutInitWindowSize(1024, 768);
glutInitWindowPosition(0, 0);
window = glutCreateWindow("bla bla bla");

InitGL();
glutDisplayFunc(&pth_main);
glutIdleFunc(&pth_main);
glutMainLoop();
return 1;
pthread_exit(NULL);
}

Thanks for any help.

Mehrdad

[jwatte]

Glut is not compatible with threading.

If you think that you can use Windows, or MacOS X, or plain Linux, for real-time uses, please note that neither of these OSes can guarantee real-time responses better than a few dozen milliseconds under stress conditions.

[Robbo]

Yea - you won't guarantee processor time with your thread - only that it will have more time than thread of lower priority and probably less time than system level code!

What are you trying to do exactly? If you don't want to drop any frames then make sure you draw\swap all of the frames - if you don't want to drop any frames AND you want a steady framerate, heres the deal:

You want to make sure you have a fast enough gfx card and processor to render your scene within the framerate bounds you set (with some to spare) - then you can hang your rendering code on a simple timer.

[remedios79]

Hi, I'm using glut and GLUI windows and multithreading.
Basicly I'm calculating an isosurface (a list of triangles) and I display the list during its construction.
What do you mean when you say that glut is not compatible with multithreading?

I have some strange problems... sometimes the program crashes without any reason and the crash is in the instruction push_back (I'm using STL).

Any idea about what kind of problem I could have?

Thank you,
Remedios

[jwatte]

The STL is also not multi-thread safe. The spec is silent on the matter, and all implementations I've seen don't do locking. You have to serialize all access to containers yourself. If you don't, you'll race and crash.

Threads really are quite a "power" tool, and if you don't take good care when using them, you'll cut yourself pretty badly.

[remedios79]

Really?

I'm finding thousands of problems in STL... gosh...

Ok, but I'm simply adding a new object to a vector with push_back, and displaying the current list of objects (triangles).

How can I lock the vector during displaying?
Thank you,
Remedios

[LordOfTheUniverse]

GLFW is multithread - safe
(i hope)

[jwatte]

Remedios,

If you don't know what synchronization primitives are available for yor platform, I suggest you take some basic threading tutorials and maybe read up a little bit on some reference material about threading and synchronization. Or, perhaps better, just give up on the threading idea.

On Windows, use a CRITICAL_SECTION. On Linux, use a pthread_mutex.

[remedios79]

Thank you for the help.
I know how to use multithreading, but thanks to a dumb professor I never used them in practice before (only pseudocode).

I know how to use mutex, but I wonder why I need it... in fact my displaying procedure do this:

for (int i = 0; i < (int)triangles.size(); ++i)
displayTriangle(triangles[i]);

and in the calculating procedure I create a new triangle, and then I push it in the vector with push_back.

So: where is the problem? The value of triangle.size() is checked run-time, and however the only problem I can have is that the last triangles are not displayed... isn't it?

Can you explain me why I need to use a mutex?

Thank you again,
Remedios

[roffe]

Can you explain me why I need to use a mutex?

I don't know how the push_back funtion is implemented, but if the size of the vector was updated before that extra triangle was added, by push_back, you might have a problem. I don't think it is implemented like that though, but it is something you shouldn't have to worry about . That is why you need the mutex.