any tutorials;)
It’s basicly just multi-threading, except that stuff actually happens in parallel.
Any specific questions?
Oh, and the volatile keyword has more importance as there are more caches, hurray
i was told java just atuomaticly did MultiCore/MultiThread
The only language I know that automaticly multithread code is Fortress, the new Sun language even multithreading for-loops 
But heck no, Java doesn’t automaticly multithread code.
The JVM from Sun does spawn multiple threads so in that respect you can say Java is automatically multithreaded. But you have to make your code multithreaded to take advantage of multiple cores.
in the recent past my game loop was like this:
while(true)
{
//handle user input
//handle AI
//render
}
right now i’m thinking of something like this
while(true)
{
//handle input
//handle AI(every object in his own java.util.lang.thread )
//render scene( opengl is one thread no MP things here
}
so in step 2 if i extends monsters with their own Thread will the JVM expand this over multiple cores?
Paul
Oh dear goat no! Yes multiple threads will run in parallel if you’ve got multiple cores, but this is not the way to do it. Firstly you’ll cause yourself all sorts of hideous syncronisation issues and race conditions. Fixing that would require considerable amounts of overhead with syncronisation. But the real killer is that context switching from one thread to another is far from free and has quite a bit of overhead. Couple that with the fact that most desktop OS’ don’t scale very well to lots of threads and you’ve got something that’ll suck up CPU time for very little actual work.
If you want to make optimal use of multiple cores you want a thread per core, then somehow figure out a way to balance all your processing between them. Breaking your loop into small tasks and having a task queue would be a good way, but it’d require quite a lot of changes compared to a normal game loop.
Like Orangy Tang said, you don’t want to let your basic game object extend Thread. A thread is a complex thing which uses scores of memory, it has its own stack, for example. You’ll probably get OutOfMemoryError in, like, no time. Aside from this, you’ll be quite unable to control the update rate since the threads are not ensured equal CPU time.
You may want a handful of threads to do different things, like networking, logic, possible other stuff. But generally it’s difficult to work with multiple threads. At least I think so.
incorect i my game i have about 5 threads running at the same time you get OutOfMemoryError at 70 or somthing (i tried)
What is incorrect exactly?
Anyway, the above statements are very true, but context-switches aren’t that bad. You can have a few dozen threads before it becomes noticable in performance.
However, you’ll need advanced knowledge of synchronisation and locks. The new java.util.concurrent package might take away most of the obvious bugs, but it’s not enough to write your entire game multithreaded.
A great debugging feature when finding deadlocks is Thread.getAllStacktraces() to find out at which lines both Threads are stuck. Unfortunately there is no Thread.getLocks() yet, only Thread.holdsLock(Object obj). These methods might make your multithread-coding life a bit easier, but there is much to learn!
As was said earlier, all java programs are multi-threaded since the garbage collector among other things runs in its own thread. Run any java program with the -Xprof option to see just how many threads there are.
Multithreading adds to complexity and can lead to bugs that are random & really hard to track down.
Also, keep in mind that for games the performance bottleneck is usually in rendering but Java2D takes care of this by using the computer’s 2 processors - the CPU & GPU - and you get this by default without even knowing it! It will be cool when Graphics cards are multi-cored.
Interestingly, on my dual-core 2.8GHz box my 2D game runs 40-100% faster in software mode than in accelerated DirectDraw mode, with the Java2D OpenGL pipeline being slightly slower (but the Mustang J2D OGL pipe line is faster than software mode ).
What I find most challenging task is having an efficient sharing of object state between gameThread and rendererThread. And no, I have not implemented such multithreaded game.
gameThread updates state attributes myCar.x, myCar.y, myCar.z, etc… and rendererThread iterates a list of objects and render the scene. Attributes must be synchronized not to be changed in a next gameThread loop while renderer is still using objects. You will ruin per-frame integrity quite easily.
Maybe you could have two or more statepools within each object and threads swap currentRendering and currentUpdate statepools (like doublebuffered thingie for state variables).
Well depending on how you look at it they already are. But in reality lets all hope that they never get multi-cored in the same way that CPUs are, all that would do is reduce the number of pipelines you could have on a single chip or introduce other inefficiencies that the current multi-board setups have.