A while back I was working in a multithreaded app where multiple threads can be creating/destroying texture resources simultaneous.
On thing i noticed is that if you have one thread call glGenTextures() and store the return value, but not bind a texture to it using glTexImage(), the same value could be generated by glGenTextures() in another thread.
However, if you bind the texture using glTexImage(), that texture ID is not free for use in other threads.
I’m writing some other code thats similar to this, and it just struck me that glGenTextures() may not be thread safe… is this the case? I’ll have to write a thread safe wrapper…
What about how the contexts are managed in your mulithreaded program ? Are they simply different threads, meaning they don’t share any GL context ? In that case, that would be normal. Otherwise, you’ll be right.
In other words, if you don’t provide full statements about what you are doing and the conditions under which you are running and testing, it will be difficult to help you or find something good.
Unfortunately, things aren’t that simple. This is a truly multithreaded mature app and there are a lot of threads and contexts floating around, getting used and reused. All the contexts are shared with one hub context so that all textures should be shared also.
I’m going to write my own thread safe glGenTextures() function. Either the driver is buggy or the GL spec behaviour isn’t very useful in multithreaded situations.
I’m writing some other code thats similar to this, and it just struck me that glGenTextures() may not be thread safe… is this the case? I’ll have to write a thread safe wrapper…
Of course it isn’t thread-safe. OpenGL isn’t thread-safe. None of the functions do any kind of semaphore logic or anything to even consider preventing an application from creating a race condition inside GL.
Actually, what you described also happens in a single thread: you get the same IDs if you call glGenTextures twice without doing a glBindTexture in between.
So it isn’t even about OpenGL being threadsafe, strictly speaking, it’s about your program being threadsafe. Which is also how you can solve it (and I note that that is already how you’re planning to solve it).