Hi everyone,
is there a best practices for multithreading in jmonkey? I created a hashtable in the simpleInitApp, which I can write to in another thread and then always work through in the simpleupdate(). But its not doing anything. The reason I created this hashtable was because removing or adding a node to the rootnode from this other thread sometimes created a thread error. But now its not attaching or removing anything from the rootnode. Any ideas?
Cheers
If you want to attach or detach a node from other thread you should use app.enqueue()
See docs:
https://wiki.jmonkeyengine.org/jme3/advanced/multithreading.html#the-jme3-threading-model
https://wiki.jmonkeyengine.org/jme3/advanced/multithreading.html#the-callable
thank you! I will try that! I always seem to get lost in the docs and never find what Iâm looking for.
more proper is just âyou need synchronize threads when using same shared variablesâ.
app.enqueue() - cause your code to wait for JME main thread update call, and then execute it.
but it dont need to solve your problem, since we dont see code and what you do exactly.
but please note, when you update hashtable in second thread, it need to be thread-safe, otherwise you will get exception too, when first thread what access it.
But your general question is âis there a best practices for multithreading in jmonkeyâ.
so i can easly say:
Yes, but when you say this, people instantly think of the âsynchronizedâ keyword⌠which is the absolute worst way to do multithreading (well, second to no protection at all).
Enqueuing is the right way whether game-specific message passing or Spatial passing. Anything else makes the render thread wait for you.
Edit: though of course itâs worth pointing out that things like Zay-ES will hide this from you and just let you not worry about it anymore.
but is enqueue() itself synchronized with synchronized list(that is same as âsynchronizedâ keyword), right? i didnt look at update queue, so i ask.
No. The java.util.concurrent stuff goes through GREAT trouble to avoid using the âsynchronizedâ keyword. A lot of things like queues can be done with no locking at all.
The java.util.concurrent stuff was a really special thing we got way back then. Prior to that, those of us who read Doug Leaâs books had to do it all ourselves and get it wrong half the time. There is a bunch of really smart work in there⌠and itâs fun reading the details in there if you ever want to really get under the skin of proper multithreading.
Fortunately, we can just use them and not worry about it.
good to know, i were using it beliving its like you say. locking is not nice.
each time i needed to synchronize threads were just using enqueue 
I actually found out, that hashtables in java are not threadsafe and that I needed to use a concurrenthashmap. I didnât really understand how I would get the enqueue() working but I found out that my simpleupdate was never called, because I forgot to pass the float tpfâŚ
Sorry guys. Its always those small things that get me searching for daysâŚ
Just a noteâŚ
Because a ConcurrentHashMap implies that you are keeping these things around and potentially modifying them again from other threads⌠once youâve attached something to the scene, you can never ever again touch it from another thread.
This is why queues are less dangerous. Finish the thread stuff, add it to the queue⌠done. Your update then just pulls the thing off the queue and does something with it.
No real chance of bad things.