Bug in GLContextLock

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in GLContextLock

opqdonut
Hi,

We bumped into a weird deadlock related to GLContext.makeCurrent(). It seems that one of our threads changes its name and this makes the following code snippet go wrong:

(GLContextLock:62)

Thread current = Thread.currentThread();
if (owner == null) {
    owner = current;
} else if (owner != current) {
      ...  // wait for lock
}

You see, the objects returned by currentThread() are not the same in our case, even though the thread is the same (the name changed). This causes a deadlock since the GLContextLock is waiting for itself :)

You should probably use Thread.equals() instead of ==. I also recommend considering some of the standard lock primitives instead of a custom one.
Reply | Threaded
Open this post in threaded view
|

Re: Bug in GLContextLock

Cyrille
Hi,

I am surprized by your statements: I can't find any overload of equals in java.lang.Thread. How could equals' behaviour be different than the built-in equality operator, then?
Moreover, are you sure it is not safe to rely on the Thread instance to identify a given thread? I always believed that Thread.currentThread() returns the same instance if and only if the same thread is current.

Regards,
Cyrille