i’m trying to develop a game using this JMonkey Engine
i learn that “simpleUpdate” function called everytime the frame updates
then it means that having too many code in “simpleUpdate” would slow down the game
my game will use many code for the AI to think, so it would be a very long code
if i’m using about 50 AI then it would be lag, definitely
is there any way to run the code separately and repeatedly ?
i have tried using thread, but when i force the window to close (Alt + F4) it seems the thread is still going, so the program doesn’t exit completely
is there a way to stop the thread after the window is closed by alt + f4 ?
and this one,
about simpleUpdate and simpleRender
since simpleRender runs after every update on simpleUpdate, is there a case where a code needs to be split in this 2 function ?
what i mean is, why does this function must be split into 2, why not 1 ?
For 1) we have some documentation on threading for exactly this example in our wiki: https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:multithreading
For 2) the engine needs to be sure that all modifications to the scene have been done (in the update methods) before it can render the scene. So the split into two methods makes sure that the engine can discern between those states (making changes to the scene vs. rendering it).
The JVM not ending means that the AI threads are marked as “non-daemon”.
Either close them down on Alt-F4, or mark them as daemon ones. (The former approach requires explicit thread management in the main window, the latter requires being careful about thread clean-up in the AI threads.)
The design choice is actually the same, except you’re now shutting down the executors instead of the threads.
…and the shutdown code is already written for you instead of having to add it to your thread subclass. (Note: thread.stop() is not a valid way to shut down a thread… the only safe way to kill a thread in Java is System.exit()… so you must make a suicide pact with your custom threads to get them to shut down.)
Well okay, I was typing a bit too fast - you don’t shut down threads, you set their isInterrupted() flag and code them so that they honor it, hopefully faster than the user decides to instakill the JVM.
Is still the same - you just do ExecutorService#shutdownNow() instead of Thread.interrupt().
Not sure what shutdown code written for me you mean - dispatching the interrupted flag to all the threads?
Because as far as I understand the mechanics, there is nothing beyond that that an executor could do.
I just re-read the docs to make sure that I missed nothing glaringly obvious, though it’s always possible to overlook something - so please correct me if I’m wrong.
@toolforger said:
Well okay, I was typing a bit too fast - you don't shut down threads, you set their isInterrupted() flag and code them so that they honor it, hopefully faster than the user decides to instakill the JVM.
Is still the same - you just do ExecutorService#shutdownNow() instead of Thread.interrupt().
Not sure what shutdown code written for me you mean - dispatching the interrupted flag to all the threads?
Because as far as I understand the mechanics, there is nothing beyond that that an executor could do.
I just re-read the docs to make sure that I missed nothing glaringly obvious, though it’s always possible to overlook something - so please correct me if I’m wrong.
With the executor services, you have to write zero extra code to get shutdown capability. You get recurring tasks, etc. for free (ie: no extra code). In many “roll your own thread” approaches there ends up being some while(true) loop or while( keepGoing ) loop that you have to check for isInterrupted, etc… None of this extra infrastructure is required and those of us who can do it in our sleep forget how easy it is to get that a little wrong and only learn that you have months down the road.
So for those new to threading, I always always always recommend the use of the java.util.concurrent stuff exclusively.
I’ve written threading libraries in my day and I still use the java.util.concurrent stuff most of the time. It does virtually everything I need and makes it much friendlier.
@zarch said:
I've written threading libraries in my day and I _still_ use the java.util.concurrent stuff most of the time. It does virtually everything I need and makes it much friendlier.
Yeah, it’s really good stuff. Many of us old dogs were essentially followers of Doug Lea long before the stuff made it into core Java.
<cite>@pspeed said:</cite>
With the executor services, you have to write zero extra code to get shutdown capability. [...] In many "roll your own thread" approaches there ends up being some while(true) loop or while( keepGoing ) loop that you have to check for isInterrupted, etc..
Hm… well, there’s ScheduledExecutorService that will do timed loops and will take care of wrapping any Runnable in a Thread for you, so that’s taking care of a lot of boilerplate for you. (And for the benefit of lurkers: you don’t instantiate any executor directly, you call one of the factory functions in java.util.concurrent.Executors, usually.)
I don’t see it covering the case of long-running Runnables though. If you have a thread that does something lenghty in the background (database updates, downloads, uploads), it still needs to check isInterrupted() every, say, 0.1 seconds. Fortunately, many library functions that do length stuff for you will do that and fail with an InterruptedException.
<cite>@pspeed said:</cite>
So for those new to threading, I always always always recommend the use of the java.util.concurrent stuff exclusively.
I’d even recommend using it if you’re an old hand with threading
That this went into direct Thread handling was just because (a) the initial post talked about threads, and (b) I’m still not seeing how executor services cover the interruption inside threads (I do see how they encourage a coding style that needs less of that )
Hm… once we reach agreement about best practices, I think I’ll update the “Java Multithreading” section in the JME tutorial with that.
The link to the Java tutorial threads starts with explaining all the low-level details, which is useful background information but can mislead a first-time reader into thinking they should use Thread and friends.
@toolforger said:
Hm... well, there's ScheduledExecutorService that will do timed loops and will take care of wrapping any Runnable in a Thread for you, so that's taking care of a lot of boilerplate for you. (And for the benefit of lurkers: you don't instantiate any executor directly, you call one of the factory functions in java.util.concurrent.Executors, usually.)
I don't see it covering the case of long-running Runnables though. If you have a thread that does something lenghty in the background (database updates, downloads, uploads), it still needs to check isInterrupted() every, say, 0.1 seconds. Fortunately, many library functions that do length stuff for you will do that and fail with an InterruptedException.
I’d even recommend using it if you’re an old hand with threading
That this went into direct Thread handling was just because (a) the initial post talked about threads, and (b) I’m still not seeing how executor services cover the interruption inside threads (I do see how they encourage a coding style that needs less of that )
Hm… once we reach agreement about best practices, I think I’ll update the “Java Multithreading” section in the JME tutorial with that.
The link to the Java tutorial threads starts with explaining all the low-level details, which is useful background information but can mislead a first-time reader into thinking they should use Thread and friends.
For the record, I was specifically addressing OP’s use-case: “is there any way to run the code separately and repeatedly ?”
One could argue, though, that many “long running tasks” that have “a lot of places to stick an isInterrupted() check” could be split into separate tasks… and not just arbitrarily but to an actual improvement overall. For the other cases you are right that the executor service provides little else in the way of benefit… except easily being able to wait for a bunch of stuff to finish before continuing in the case where you have lots of these going.
Is there a consensus that the wiki section on Java Multithreading should be rewritten to highlight Executors? I’d be willing to do that.
Either as part of that section or as a separate one… something needs to be done, though.
Along with advice like “before you use the ‘synchronized’ keyword think hard about your threading design and make sure there isn’t a java.util.concurrent construct that helps”.
I’m off topic, I know but for this kind of stuff I’ve come to really like the Google Guava libraries http://code.google.com/p/guava-libraries/wiki/ServiceExplained
I’m using it for a non-jME project. I’m running my physics engine (dyn4j) as a service (also network code and rendering as services). It’s a really nice library that doesn’t hide the java.util.concurrent stuff, just takes care of a little boilerplate.
@jmaasing said:
I'm off topic, I know :-) but for this kind of stuff I've come to really like the Google Guava libraries http://code.google.com/p/guava-libraries/wiki/ServiceExplained
I'm using it for a non-jME project. I'm running my physics engine (dyn4j) as a service (also network code and rendering as services). It's a really nice library that doesn't hide the java.util.concurrent stuff, just takes care of a little boilerplate.
Yeah, I pretty strongly recommend guava in general. The threading related stuff is relatively minor in comparison (which just goes to show how good all of the other stuff is).
