[Solved] Thread error when attaching or removing nodes to root node from another thread

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?


If you want to attach or detach a node from other thread you should use app.enqueue()

See docs:



1 Like

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:

  • keep Spatial(it is Node/Geometry/etc) updates/controls/anims/Physics/etc only in main thread. everything else can be in second thread.
1 Like

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.

1 Like

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 :slight_smile:

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…

1 Like

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.