I was wondering about how thread-safe the Vector3f in JME2 is.
From what I see, JavaGameNetworing for example seems to do everything on another thread and just modify the Vector3fs of the Spatials it controls as it comes, whereas JMEPhysics2 does the syncing on the OpenGL thread.
I am aware that some computation errors might arise but is it safe (as in exception-safe) to modify the content of Vector3fs that are used in the OpenGl thread?
Imagine this. Let's say a certain vector is used as a translation for an object in the OpenGL thread, and a reference of that vector is modified in the network thread:
public void set(float x, float y, float z){
this.x = x;
this.y = y; // <--- here
this.z = z;
}
The network thread is where the arrow is, the x and y have been set on the vector, but z was not set yet. Now we switch from the network thread to the OpenGL thread and the object is rendered with the current translation, which is wrong, since the x and y have been altered to contain a certain value while the old z stayed.
Yeah, thats what I meant by saying "some computation errors might arise". But it does not answer my question. The JME example in JGN for example does not care about this.
They are not thread safe, (as floats are not thread safe)
oO really, I thought float were atoms in java? I suppose I just had luck in my other project then xD
Thread safety is something I battle with all the time. Not in JME, but in our multi-threaded trading system. Because thread conflicts are so few and far between for an example above, they basically become impossible to analyse because reproducing them is ridiculously hard.
You just have to code as safely as you can. Can I suggest you look at the java.util.concurrent.atomic classes. You might wish to play around with the AtomicReference class.
For my game, I am using a thread-safe queue (ConcurrentLinkedQueue) with "jobs" that the main thread will handle. Other threads post jobs such as "updateVectorXXX", and the main thread does this. I'm finding this very fast so far, but I am only posting around 20 "messages" a second. I imagine if you need to up your game, you will need to Atomic 
Cheers
Richard
Thanks, I have some experience with multithreading and seldom got to the situation where I have an unprotected float but I always thought the basic variables (int,float etc) are atoms in Java…
Lately, I found that the best way to multithread is on a small scale and more often. Thinking less like "This thread for physics, this for AI" but setting up a thread pool and working with Callables/Futures wherever there is a for loop or something similar. It seems to be a bit more "dangerous" but in facts its less, because you have the multithreading going on with just a small amount of objects at a time, mostly even all packed in one method… And it scales to multiple (more) processors way better… I was experiencing good results with this in an audio application I am developing.
normen said:
Lately, I found that the best way to multithread is on a small scale and more often. Thinking less like "This thread for physics, this for AI" but setting up a thread pool and working with Callables/Futures wherever there is a for loop or something similar. It seems to be a bit more "dangerous" but in facts its less, because you have the multithreading going on with just a small amount of objects at a time, mostly even all packed in one method.. And it scales to multiple (more) processors way better.. I was experiencing good results with this in an audio application I am developing.
I would hope that an application developed in that manner can expect to have the hardware mostly to itself ;)
normen is absolutely right. When you have 2-4 cores having a separate thread for AI, audio, etc works fine, but when you go 8 threads and more this doesn't work.
You gotta split each part into tasks and have a main thread that gives out these tasks. So when it comes time to do AI for the current frame, you just create an update AI task for all NPCs in your game and send these task to the Executor (java.util.concurrent class).
Well I kinda follow a the functional approach in Programming,
when you have a object make sure you only manipulate it from one Thread, but allow each thread to send to each other "messages" with what they want to be done.
However the minimized multithreading aproach like described before sounds kinda intresting to (and I can easily combine it with mine)
However keep in mind, that Threads are kinda heavy ressources, im many cases it just does not matter if its multithreaded at all, since it only works great if there is a low "interaction between threads"/"processing power needed" ratio