Answers Please.
Yes…well, kinda, since it doesn’t allow access to one rendering context from multiple threads.
Excerpt from MSDN about wglMakeCurrent:
A thread can have one current rendering context. A process can have multiple rendering contexts by means of multithreading. A thread must set a current rendering context before calling any OpenGL functions. Otherwise, all OpenGL calls are ignored.
A rendering context can be current to only one thread at a time. You cannot make a rendering context current to multiple threads.
An application can perform multithread drawing by making different rendering contexts current to different threads, supplying each thread with its own rendering context and device context.
Thanks for the reply Asgard.
You helped me yesterday too. Thanks.
Anyway, you’re right, I was aware of that. Besides this are there any other multi-threading issues with openGL. If not, is the only opengl-related resource we need keep track of and properly arbitrate the rendering contexts?
Thanks for the reply Asgard.
No worries, mate 
Besides this are there any other multi-threading issues with openGL.
Not that I’m aware of. Every thread gets its own context+DC and off you go.
There are other issues. If you have multiple contexts and they share textures, you need to manage how the updates happen if the contexts are in separate threads. There are other similar issues like this with having two contexts bound to the same drawable. In general, it is supposed to not crash, but you need to pay attention to synchronization to get predictable results.
-Evan
If you have multiple contexts and they share textures
Ah yes, didn’t think about sharing objects.
There are other similar issues like this with having two contexts bound to the same drawable.
Hm, I actually thought that’s not possible to use the same device context. At least that’s the way I interpreted this (from the MSDN):
An application can perform multithread drawing by making different rendering contexts current to different threads, supplying each thread with its own rendering context and device context.
…since it says “supplying each thread with its own device context”.
But I guess it makes sense to support multiple contexts for a single drawable for doing stuff like different views of an editor using viewports.
Just in case anyone still uses GLAUX, that’s not multithreading safe.