I have several questions:
-Writing a game using 4 GameStates means it's in 4 separate threads, correct? (i.e. # of GameStates = # of Threads?)
-Java automatically sends extra threads to extra processors, correct? So if I have 4 threads in my game it will send one to each core of a quad-core processor?
So if both of the above statements are true and I'm using 4 or more GameStates my video game takes advantage of Quad-core processors?
From what I've seen debugging my StandardGame application, I believe there are only two threads used:
- The "main" thread
- The "OpenGL" thread
Sorry, but I don't know nearly enough about Java to know how it handles threads and processors.
I don't know the answere, but I'm sure the four cores are used. Which thread on which Core you cant control, I think. for the Programmer its not so important, because the JVM controls this. I work here on an SingleCore Machine (ok, it has hperthreading) with lot more than 4Threads, and I feel its faster, than only one Thread.
I don't think a GameState creates a Thread. It will be executed in the thread, where you call the methods.
Standardgame has two Threads.
If you don't do threading yourself, its this way:
You instantiate the Gamestates in the mainthread (where you call eg game.start()) and add it to the Gamestate Manager. Perhaps you call some init Methods of a gamestate in this thread - so you need perhaps callables because you aren't in the opengl thread.
The gamestate.update() and gamestate.render() methods will be invoked in the openGL thread automatically by standardgame, so these methods don't need callables but are blocking rendering.
See StandardGame.class, the run() method.
If you want to use more than these two Threads, you'll have to create new Threads by yourself.
In Java there are 2 kinds of threads, if i remember correctly. Green Threads and Native Threads. Green Threads are only threads in the JVM, and native threads are real threads in the OS (and on the processor cores). I think Java handles this by itself (spawning greenthreads if there aren't any cores left or so, theres a lack of my knowledge)
Threading is a very complicated topic. Theres somewhere on suns documentation a good tutorial about this.
Greets
snare
A game state is not a thread.
Each gamestate is given a piece of the processnig time of a single main game thread.
Trussel, yes, I believe so. Each game state should be a thread. JGN has it's own gamestate, and I know that starts a thread.
From what I have found out:
No a gamestate is definately not a thread on its own!
The update and render method of every gamestate are executed inside the one and only GL thread.
What I did lately with success was creating new threads (e.g for messaging purposes) out of an update or render method of one or more gamestates
GameStates are not executed each in their own thread. That would be a total mess as you can't control what executes first. They are executed in the GL thread by order in the game loop.
If you want to multithread your application, IMO it's best to do so for individual tasks + independent processing. E.g audio, network and resource loading can all go into their own threads as they are independent of the game loop, you just send some commands into a queue and the threads process that queue.
Other tasks can greatly benefit from parallel execution, e.g animating a character, if you have 32 characters on the screen and 16 processors, you give 16 threads 2 characters each to handle, thus reducing the processing time required by 16 times. In the future this is probably how you will be forced to do multithreaded programming as there will be tons of not-very-fast-cores, you have to cleverly split up your tasks into a unit that each can be handled independently of the others.
Oh, I must have been confused. I know that there are at least two threads, the main thread, and the GL thread. Then I believe JGN starts it's own threads, but no through gamestates.
Momoko_Fan said:
GameStates are not executed each in their own thread. That would be a total mess as you can't control what executes first. They are executed in the GL thread by order in the game loop.
If you want to multithread your application, IMO it's best to do so for individual tasks + independent processing. E.g audio, network and resource loading can all go into their own threads as they are independent of the game loop, you just send some commands into a queue and the threads process that queue.
Other tasks can greatly benefit from parallel execution, e.g animating a character, if you have 32 characters on the screen and 16 processors, you give 16 threads 2 characters each to handle, thus reducing the processing time required by 16 times. In the future this is probably how you will be forced to do multithreaded programming as there will be tons of not-very-fast-cores, you have to cleverly split up your tasks into a unit that each can be handled independently of the others.
So if I have a class called "TerrainUpdater" that extends Thread and I start that class it'll be running on the third core? And if I have one more thread that I use for Audio like you said, and I start that, it'll be up to 4 threads (i.e. using all four cores)?
I can recommend the tutorial on sun's page:
http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html
I must admit that I am not very experienced in thread-programing. I once did a SwingChat which really works^^.
Momoko_Fan said that threads can be handled indenpendently if the programmer do so:
...have to cleverly split up your tasks into a unit that each can be handled independently of the others.
That's only one way to use threads but its the most simple. Threads can also depend on each other for example thread B can only load some data if thread A has located and opened the file.
The join method allows one thread to wait for the completion of another. If t is a Thread object whose thread is currently executing,
t.join();
causes the current thread to pause execution until t's thread terminates. Overloads of join allow the programmer to specify a waiting period. However, as with sleep, join is dependent on the OS for timing, so you should not assume that join will wait exactly as long as you specify.
Like sleep, join responds to an interrupt by exiting with an InterruptedException.
Thread dependencies require synchronization (semaphores, locks, atomic statements, critical sections) and should handle interrupts as todays Operations Systems usually do preemtitive scheduling (threads can be interuppted during execution).
Each thread has the possible stati create, ready, running, suspend, treminate. And the os dispatcher assings a thread in ready status to a processor to start running.
One problem using multithreading is that the stack size must be dynamic.
I would like to know if I can create many and big new threads from the same parent thread? I would like to ensure that no OutOfMemoryError occures anymore. Is the process owning these threads dynamically in memory allocation or is a knew thread bounded by the fixed size of the process?
Wow, I'm actually quite astonished at how many of you believe that each GameState is in fact its own thread. Nor does JGN necessitate having its own thread, but may have one or several depending on how you configure it. StandardGame creates and manages a single thread, but that thread is removed from direct utilization in your game. Since all OpenGL rendering needs to be done in one thread StandardGame attempts to manage that for you keeping it running smoothly and where possible you should try to do any "work" outside of that to keep your FPS from dropping.
I'm curious how many of you have read the tutorial on the wiki about threading with StandardGame? I'm wondering if I just did a bad job of explaining this or you haven't read it. 
I read all of them. I was pretty sure the OpenGL thread and StandardGame thread were different, since I do have problems with the OpenGL thread running faster than the StandardGame thread. I know have to lock the game during initialization.
Well now that I understand each GameState is not it's own thread, all I have to do is create new threads and use Callables to use OpenGL calls, and I'll have quad-core support.
I'm thinking I'll have a thread for the following:
- OpenGL thread (obviously…)
- Terrain and Vegetation Loading
- Loading characters into the world.
- Audio OR Networking (like chat, etc)
It's actually quite simple…just throw it work and it does it…just implement WorkUnit in a unit of work that needs be done and call the addWork(workUnit) and it will be done for you in a non-blocking, multi-threaded way.
You’re probably better off using a work management system. I’ve written a pretty advanced one in my xjava project if you’re interested:
http://xjava.googlecode.com/svn/trunk/src/org/xjava/work/ThreadManager.java
http://xjava.googlecode.com
Since creating and destroying threads is very expensive this manages threads for you and reduces complexity since you no longer have to think about using/re-using threads to accomplish your work, but simply pass off work units to be done and ThreadManager makes sure it gets done.
Having taught myself everything I know about threads (and that was just from skimming the Java tutorial), I'm not sure how I would ever utilize something that complicated.
Perhaps later down the development path I will come back to you and ask how I should implement something like that.
Wow, that does seem pretty easy. So I implement WorkUnit in a series of classes, fill the doWork() method with what I need it to do, and then I add all of my implementations to the ThreadManager, and it takes care of everything from there?
I assume I can pass it variables it might need (i.e. the terrain nodes, character nodes, etc.) through a constructor, correct?
Each WorkUnit implementation is executed as it's own thread–no automatic dividing among processors, right? So for each WorkUnit implementation I put in, that's one more processor I'll use (obviously never exceeding the maximum)?
There are additional methods in WorkUnit you have to implement to use it, but you can also leverage RunnableWorkUnit that takes a Runnable in the constructor if you don't want to bother with those other methods…although those methods are relatively simple.
ThreadManager simply has several managed threads that are constantly looking for work to do and asking ThreadManager for something to do. When ThreadManager has work in it to return it simply gives it to the first work thread that is looking for something to do. ThreadManager itself is essentially a work queue and the worker threads constantly poll it. There are a ton of complex features that you can make use of, but at its root that is what it provides you and I believe is quite simple.
No, it won't exceed the maximum unless you give it too much work that has a priority of HIGH and then it will overflow the thread-count but once the load has reduced there is a cool-down period where it will start killing off the overflow threads back to the maximum. It's quite an intelligent system if I do say so myself. 
Does your library have any similarites with the java.util.concurrent package?