Shader Parameters & Multithreading

[Z01]

I'm using OpenGL in a multithreaded application. My shaders each have a lock so more than one thread cannot be changing a fragment program parameter at the same time. I basically:

*lock the shader
*bind it
*set its parameters (since another thread could have changed them, I always have to reset them)
*render with it
*unlock it

My question to the forum members is whether this is sufficient protection against multithreaded bugs in practice?

(eg. Could a second thread using the shader soon after the first thread released it, set its own parameters and this messes what the first thread was trying to do?)

[Korval]

(eg. Could a second thread using the shader soon after the first thread released it, set its own parameters and this messes what the first thread was trying to do?)No more than that could happen in a single-threaded application.

BTW, one lock per shader can be quite a few locks. And it doesn't deal with other non-shader things (images and the like). It makes more sense to have a single GL lock that prevents other threads from accessing any GL function until that lock is released.

[Zengar]

Only one thread can call GL functions anyway, as a conetxt is bound to a thread and not to the entire application. So you won't be able to change shader uniforms from another threads.

Or did I missundertand something?

[Z01]

Thank you.

Korval - regarding there being lots of locks: Having a lock per shader is not something I like doing or do lightly, but it is forced upon me by the structure of the (quite large) existing codebase/application I'm working with.

Zengar - my understanding is that shaders are shared between contexts when you call wglShareLists(). So you could have threadA on contextA using the shader, then at the same time threadB on contextB could be wanting to use it.