Hello,
I'm experimenting with JMECanvas in Swing application.
I had a problem with method call TerrainPage.updateFromHeightMap() throwing null pointer exception.
Finally I realized that the method needs to be executed in OpenGL thread.
Now I am uncertain what stuff suhould be executed in OpenGL thread and what can be executed in AWT thread.
After a quick look at the JME src it seems that canera and texture updates should be done in OpenGL thread.
Does anyone have a complete list of things that should be done in OpenGL thread?
No, there is no official list, but that sounds like a great thing to add to the wiki.
Or we could simply fix it so those calls don't have to be made in the OpenGL thread. 
so do you have the list with things to fix? 
Judging from Darkfrog's comments it should be reallllly easy to fix.
yeah, by adding another thread somewhere :evil:
(sorry DF, i can't hold it back )
Everything is easy for DF, one can but hope to reach such heady heights of awesomenessedness!
But for us lesser tree dwellers, where be this list?!
renanse said:
Judging from Darkfrog's comments it should be reallllly easy to fix. ;)
Of course it is. It's a simple two-step process:
1.) Complain about it
2.) Renanse finally gets sick of it and fixes it
:P
Damn it, don't spread that formula or everyone will be doing it.
Posting on the internet is like peeing in a pool…once it's in there it's impossible to get out.
Note to self: Never go swimming at Darkfrog's house
Also this sounds like a great use for an annotation!
@GLThread
or something. That way it's human readable in the source and generating a list would be easy as pie!
and where for example would you put that annotation? on all methods which should be called only in the GL thread? there are many such methods.
sfera said:
and where for example would you put that annotation? on all methods which should be called only in the GL thread? there are many such methods.
Well thats the point! They either need to be made Thread safe or everyone needs to be warned to make sure they get called in the GL thread (even more so thanks to StandardGame).
Check out how many posts lately have been because of GL calls not made in the GL thread. With a list everyone would know and everyone would be able to attempt making jME more thread safe (DF would love it!).
Also if we start start marking them up I bet we'll come across a bunch of methods that must be called in the GL thread even though theres no real need for them to be.
Java concurrency in practice (http://jcip.net/) talks alot about documenting thread safety (which most definetly means documenting lack of thread safety).
They use some good annotations to generically denote thread safety (might be a little strict, but that helps when it comes to thread safety), and you can download their annotation source code here:
Concurrency annotations: jar, javadoc, source
They define 4 basic thread safe annotations:
- @GuardedBy - Defines what object provides the synchronized lock for this field or method
- @Immutable - This class is immutable meaning all public fields are final, all public final reference fields refer to other immutable objects, constructors and methods do not publish references to any internal state which is potentially mutable by the implementation.
- @NotThreadSafe - for clarifying the non-thread-safety of a class that might otherwise be assumed to be thread-safe, despite the fact that it is a bad idea to assume a class is thread-safe without good reason.
- @ThreadSafe - This means that no sequences of accesses (reads and writes to public fields, calls to public methods) may put the object into an invalid state, regardless of the interleaving of those actions by the runtime, and without requiring any additional synchronization or coordination on the part of the caller.
Unfortunatly none of these really describe what's needed for jME. This is really useful if you instance objects yourself, and use them for "general threading purposes" so to say.
In jME however, there's really only one "object" that is created (usually only once), that has some of the properties of "@NotThreadSafe". Even then the problem is that it's not even a real java object, but it's a native context accesed through static methods.
I suppose an annotation could be used to mark methods that (potentially) use these other methods… but it'll be not much more than a "pretty looking" comment in the source.
I personally think it'd be most useful to give some kind of warning if you attempt an LWJGL method from the wrong thread. I wish debuggers could do that (package wide thread aware breakpoints) but afaik they can't yet… it shouldn't be too hard to make some kind of "debug" LWJGL library (most of their code is generated already I believe). I can understand why there's no such thing yet, most LWJGL developers don't use threads much, or if they do, they're much "closer" to the actual library, while with jME you can LWJGL all the time without even knowing what it is.
Yeah, I was thinking that as I wrote it that really jME has a very specific single LWJGL GL thread safety issue, but still if developers need to know what methods of the jME library need to be called from the GL thread then that means their user code runs in a seperate thread(s). Which means that besides using the LWJGL specific calls they're using the non-GL jME library methods and assuming they're thread safe (or providing their own user synchronization, but still they need to know which objects need synchronization).
Maybe it's a whole other task to create jME thread safe wrappers, or am I just way off base and is most of the non-LWJGL jME library thread safe already (Math library, terrain library etc)? One of the major warnings from the concurrency in practice book, is that even simple things that you believe are thread safe are not, due to things like object reference escape during construction, stale values in cache because of the java memory model.
Making jME properly thread safe is a huge effort and something that would likely benefit from a good plan and tight focus from all developers. IMHO, we should wrap up our 1.0 base featureset first before tackling it. In the meantime, a general pointer list about multi-threaded jme use would be good. A completely exhaustive list is probably not possible.
Agreed, to make it completely thread-safe does require planning and full involvement of all developers, and if it was being done ad-hoc while jME is in active development it would probably just lead to poor performance and possibly hilarious deadlocks (well not so hilarious).
I'm working on some multi-threaded research, so I'll be sure to post information as I find it to the forums and once I formulate it into something workable to the wiki.
darkfrog's got a good start with StandardGame, so hopefully there will be more tutorials and examples of multithreaded jME.