I seem to be having no problem deadlocking JOGL on my DP 2.0 G5. I have several threads running: Animator, AWT-Event, Main, and some other threads. I am running without the single thread model. The rationale for the single thread model is that the issue is with the driver. My exploration suggests otherwise. There may be issues in the driver I have not yet encountered, but the issues I am seeing are all in Java. The deadlock appears to happen over contention between the AWT tree lock, and the OGL Context lock. It is pretty easy to deadlock them with a long init() method. It looks like the makeCurrent call or related method is holding onto a lock on the context while the init method is running. This is very dangerous, as user code can do anything and take any time to run. Testing on a dual processor system makes these issues much easier to find. JProfiler seems to do pretty good deadlock and monitor reporting. I am going to try moving some of the code to the AWT thread that might impact the AWT tree lock, and see how this goes.
Can you post stack traces of the threads involved when the deadlock occurs? We had to add workarounds in the Windows port of JOGL to ensure that deadlock couldn’t occur in situations like reshapes occurring on the main thread. Actually, if you can get these stack traces (maybe Ctrl-\ or kill -QUIT [pid] will help) please just file a bug with the JOGL Issue Tracker and include them.
This occurred when doing a setSize on the main thread was processed at the same time as the init method was still executing on the Event/Animator thread. I normally do not encounter this, but it happened when using a profiler (that slows everything down). It should occur with setSize() after creating a frame with GLCanvas who’s init() method (on the listener) takes a long time to run.
I have addressed this for my app by doing invokeLater in the initMethod for the part that was long running, and could be separated from the drawable. In my case that was creating the scene geometry and related Java objects.