I had thought that I understood threading and OpenGL, but I seem to be experiencing some multithreaded bugs and its made me question myself. Perhaps they are just driver issues because I'm off the beaten video game path. I wanted to sort of play a true/false game to check if my understanding agrees with everyone. Also I'm more interested in what is the best practice (that will help me avoid driver quirks rather than what the GL specification says which is somewhat incomplete with regards to multithreading shared contexts imo).
1) If contextA is current to threadA and contextB is current to threadB and the contexts have been previously shared, do we have to worry about thread protection/mutexes? I'd assume that in the driver contextA and contextB share a table of textures and furthermore since OpenGL is not thread safe then we need explicit protection for modification of existing objects and whenever creating/destroying objects:
(a) to prevent threadA and threadB from modifying the same object at once and
(b) to handle the case where the texture table could be modified simultaneously by multiple threads at once. eg. suppose contextA creates a new texture ID and the driver decides it needs to grow the shared texture table data structure whilst at the same time contextB is attempting to bind a texture from the very same table
2) If I have shared contextA and contextB and now wish to delete just contextB but continue to use contextA then its safe to delete it, but both must be not current (or just no OpenGL operations must occur on contextA during wglDeleteContext?).
3) If I create contextA and contextB on the same thread then they must be shared on that same thread or the driver may become upset.
4) If I want to share contextA and contextB they must be created on the same thread or the driver may become upset. Said differently: you shouldn't share contexts that were created on different threads.
5) It is not required but it is the best practice to share your new context before you create any GL objects on it. ie. always share new empty context with existing context
6) It is not required but it is the best practice to have one hub context (that you never use except to share contexts with) which all other contexts share themselves with