For those finding this thread later, let me follow up and re-state that my previous post was based on what I've read. I haven't actually done this (shared a single context between multiple threads) myself, as I haven't needed this ... yet. Various sources (e.g. random googles here, here)) assert you can use the same context from different threads with locking, but I of course defer to those that have sifted the spec on this issue. Apparently, this behavior is not guaranteed to work, and so while we might be able to do this, if the assertions are true, we should avoid it.

However, you piqued my curiosity Bruce, so I went looking through the GLX spec. Didn't find what you mentioned. Got a pointer? Though (related) I did find:

Quote Originally Posted by GLX 1.4 Spec
Each thread can have at most one current rendering context. In addition, a rendering context can be current for only one thread at a time.
This in-and-of-itself doesn't preclude multiple threads accessing GL through the same context, so long as they don't ever both have it active simultaneously. It also seems curious wording if you should only make the thread current in the thread that created it... Why would this even be allowed?

Elsewhere in the spec we find:

void glXDestroyContext( Display *dpy, GLXContext ctx );

If ctx is still current to any thread, ctx is not destroyed until it is no longer used.
Again, this seems odd wording if GLX contexts cannot be shared between threads. I mean if that really is the case, then why wouldn't glXCreateContext bookmark the thread ID in the client state and reject all attempts to make it current in or destroy it from any other thread?

Things that make you say "hmmmmm....."