On a practical note, I have a system up and running which uses several threads with a single OpenGl context (background texture loader, rendering system, and logics system, each of these may call varying GL commands), and I have yet to see any system this causes problems on.
There are a few things you need to be careful with, though:
- Be sure that all your threads always leave the GL system in some definite state (i.e. if the loader thread loads a new texture target, it changes the current binding => your renderer needs to rebind)
- Don't forget to call wglMakeCurrent once before calling gl commands, that had me stumped for some time (just forgot about that once, and spend weeks debugging my texture loader )
- Make sure that you only release your critical section after you finished an entire group of gl commands (don't, for example, exit between glBegin() and glEnd())
In regards to whether multiple threads are allowed for a single rendering context, check this quote from the MSDN:
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.
The interesting bit is: "A rendering context can be current to only one thread at a time", the "at a time" in particular. I think this means, in conclusion, that at different times, the context may be current to more than one thread.
The last part finally refers to multithread, multitarget rendering, I guess, considering they talk about per-thread unique DCs and RCs.