Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Thread spawning or Thread pool  (Read 665 times)
0 Members and 1 Guest are viewing this topic.
Offline Yemto

Junior Member


Exp: 3 years



« Posted 2013-12-25 02:29:01 »

I'm currently making a RPG game in java, and have been thinking of moving on to multithreading. But I don't know what I should use, thread spawning or thread pool. Which one should I use? and why?
Online SHC
« Reply #1 - Posted 2013-12-25 03:51:34 »

Why do you want to use multiple threads? Any specific reasons? Using multiple threads is a bad idea in games and it leads to many problems.

Offline Yemto

Junior Member


Exp: 3 years



« Reply #2 - Posted 2013-12-25 04:17:11 »

Why do you want to use multiple threads? Any specific reasons? Using multiple threads is a bad idea in games and it leads to many problems.

Please stay on topic, this thread is about what type of mutlithreading I should use, not why I do it.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 128
Projects: 4
Exp: 3 years



« Reply #3 - Posted 2013-12-25 04:30:40 »

Why do you want to use multiple threads? Any specific reasons? Using multiple threads is a bad idea in games and it leads to many problems.

Please stay on topic, this thread is about what type of mutlithreading I should use, not why I do it.
That's about as on topic as you can be. There's obviously no point asking for multithreading solutions if you don't need it in the first place. Multithreading isn't like implementing game mechanics; you don't implement it when you want, you implement it when you need it.
Offline Yemto

Junior Member


Exp: 3 years



« Reply #4 - Posted 2013-12-25 05:18:21 »

That's about as on topic as you can be. There's obviously no point asking for multithreading solutions if you don't need it in the first place. Multithreading isn't like implementing game mechanics; you don't implement it when you want, you implement it when you need it.

This isn't a topic about which threading i should use. I specifically as for what type of multithreading is best for a game. Even if none of them are better than single threading. Please let me struggle, and fail if I must. At least I learn exactly why it shouldn't be used.
Offline theagentd
« Reply #5 - Posted 2013-12-25 06:21:46 »

Your original question does show that you may be lacking when it comes to experience, so it's understandable that people would discourage you. Multithreading is very complicated to get right.

To actually answer your question: When it comes to games (or when performance is extremely important in general) you should avoid creating expensive objects each frame. New instances eventually add up and the garbage collector has to be run. When it comes to threads however you should avoid creating lots of them not because of the garbage but because threads are relatively expensive to create. You may also encounter slightly weird timings since it may take a relatively long time to start a new thread, so creating a new thread each frame to run a specific task is generally a bad idea. Pooling threads and distributing tasks to them using a blocking queue has better and (more importantly) more predictable performance.

Might as well add a shameless plug... I'm developing a threading library for games which allows you to split your game up into individual tasks and then set up complicated dependencies between these tasks. The library will then identify which tasks that can be run in parallel and distribute them to the threads in a thread pool. I suspect that this isn't exactly what you're looking for, but it can help you skip the boring thread management and let you focus on learning about multithreading games and synchronization if that's what you're after.

Myomyomyo.
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #6 - Posted 2013-12-25 06:22:41 »

You won't get any better feedback unless you tell us what you are planning to use the threads for. Asset loading in background? Separate thread(s) for socket/multiplayer? etc...

Offline tom_mai78101
« Reply #7 - Posted 2013-12-25 06:51:41 »

At least I learn exactly why it shouldn't be used.

Easy.

Do these in order!!
If you really want to use multithreading, first rule is to learn beginner's FAQs on multithreading:
http://stackoverflow.com/questions/2121617/can-someone-explain-threads-to-me/2121638#2121638
http://stackoverflow.com/questions/671049/how-do-you-kill-a-thread-in-java
http://stackoverflow.com/questions/2213340/what-is-daemon-thread-in-java
http://stackoverflow.com/questions/2275443/how-to-timeout-a-thread
http://stackoverflow.com/questions/877096/how-can-i-pass-a-parameter-to-a-java-thread
http://stackoverflow.com/questions/578904/how-do-synchronized-static-methods-work-in-java
http://stackoverflow.com/questions/5483047/why-is-creating-a-thread-said-to-be-expensive
http://stackoverflow.com/questions/1050592/do-spurious-wakeups-actually-happen
http://stackoverflow.com/questions/289434/how-to-make-a-java-thread-wait-for-another-threads-output/289463
http://stackoverflow.com/questions/20767739/will-threads-make-my-game-run-consistently-on-every-computer
Second rule, learn about differences:
http://stackoverflow.com/questions/541487/implements-runnable-vs-extends-thread
http://stackoverflow.com/questions/1036754/difference-between-wait-and-sleep
http://stackoverflow.com/questions/200469/what-is-the-difference-between-a-process-and-a-thread
http://stackoverflow.com/questions/37026/java-notify-vs-notifyall-all-over-again
http://stackoverflow.com/questions/574240/synchronized-block-vs-synchronized-method
http://stackoverflow.com/questions/6367885/difference-between-synchronizing-a-static-method-and-a-non-static-method
http://stackoverflow.com/questions/4168772/java-concurrency-countdown-latch-vs-cyclic-barrier
http://stackoverflow.com/questions/409932/java-timer-vs-executorservice
http://stackoverflow.com/questions/1179620/seeking-clarity-on-java-scheduledexecutorservice-and-futuretask
Third rule, how to apply what you've learned:
http://stackoverflow.com/questions/3984076/what-are-the-advantages-of-using-an-executorservice
http://stackoverflow.com/questions/15429474/multithreading-with-scheduledexecutorservice
http://stackoverflow.com/questions/13993911/java-handling-errors-in-repeated-task-using-scheduledexecutorservice
Fourth rule, understanding how to handle exceptions thrown by these multithreaded problems:
http://stackoverflow.com/questions/6662539/java-thread-exceptions
http://stackoverflow.com/questions/6316616/java-exception-handling
http://stackoverflow.com/questions/2248131/handling-exceptions-from-java-executorservice-tasks
http://stackoverflow.com/questions/3184883/concurrentmodificationexception-for-arraylist
http://stackoverflow.com/questions/1310532/deleting-objects-from-an-arraylist-in-java
And finally, fifth rule, what problems can be caused by multithreading:
http://stackoverflow.com/questions/1392315/problems-with-singleton-pattern/1392387
http://stackoverflow.com/questions/720244/multi-threading-and-java-swing-problem
http://stackoverflow.com/questions/12554390/producer-consumer-multithreading?rq=1
http://stackoverflow.com/questions/20660672/how-to-improve-performance-on-two-thread-accesing-a-collection-of-items-concurre

After completing the sessions from above, you've learned multithreading and have at least a professional-looking background experience.

Additional info on multithreaded unit testing, something that I think it's worth it look at.
http://stackoverflow.com/questions/12159/how-should-i-unit-test-threaded-code

You should probably thank me for compiling all of these informations that were provided by StackOverflow.
Offline philfrei
« Reply #8 - Posted 2013-12-25 09:15:11 »

Threads are fascinating and multithreading will only become more valuable as multicore cpus become more prevalent. However, experimenting with them could very likely lead one into writing a game that is unlike, in some fashion, the thousands of clones currently being generated by game engine programmers, and we can't have that, can we??  Stare

I'd put the question in two stages. The first is whether the cost of managing either spawning or pooling is justified to begin with. That is where most of the answers seem to be landing in the negative for "traditional" game applications. Perhaps they haven't considered this: "No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 Spaceships" http://blog.paralleluniverse.co/

The second stage probably can be related to general tradeoffs about spawning or pooling in general. Spawning has more overhead per unit spawned (creation, garbage collection). Pooling has an up-front overhead greater than spawning (building the pool), but once the pool is created, managing the objects can potentially be less overhead since creation and garbage collection are avoided.

So, it is kind of like a classic breakeven analysis with "fixed" and "variable" costs. Spawning has more variable cost, pooling has more fixed cost.

A lot will depend on your intended use. How long will the thread run? How many threads at once? How much reuse are you looking at? Brian Goetz ("Java Concurrency in Action") points out that frequent, light-weight use of threads creates significant costs in building and tearing down the threads. If that is your scenario, then pooling is indicated.

If the threads will get a lot of use once made, and will be built infrequently, maybe spawning is better.

I don't know if there is a way to determine this except by trying and experimenting and profiling.

However, Brian Goetz does give this equation for tuning the size of a thread pool (in "Java Concurrency in Practice", 8.2):

1  
2  
3  
4  
5  
6  
7  
8  
N = number of cpus 
U = target cpu utilization, 0 <= U <= 1
W = wait time
C = compute time

The optimal pool size for keeping the processors at the desired utilization is:

    Threads = N * U * (1 + W/C)


The point is that one thread per cpu makes a certain sense, but if the threads spend a lot of time in a blocked state, it might make sense to use more threads than there are cpus. But Goetz also points out there may be other constraints affecting the best number of threads in a pool, such as external resource availabilities.

I hope all this adds something to the discussion, even if it isn't a clear rule-of-thumb answer.

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Offline ctomni231

JGO Wizard


Medals: 98
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #9 - Posted 2013-12-25 09:37:13 »

Old Discussion on Game Threads
Okay, completely off-topic, but it does help to know that the history of games and creating multiple threads doesn't go without animosity.

Thread Spawning vs. Thread Pooling

For games, thread spawning always works better for me. Whenever I use a thread pool, it is just cumbersome for games because you have better things to manage than an array of thread workers eating up CPU time for nothing. In other words, there is really no reason in games I can think of where a constant running thread pool would yield an advantage.

You have to think about, when a user will be using this?
Probably only during the main game...

How many things in my games need a separate thread?
Usually, not many and the thread work is usually finite.

Especially in an RPG, I already know that there is probably nothing that CPU intensive anyway. Did you really want the CPU running when your user decides to pause the game? Really?

In games, you want to use as much resources as you can to get the data to the screen. All this fancy threading stuff, leave that for cell generation demos, or space eruption simulators. A game should be focused on user enjoyment, not technical stuff that eat CPU time for no reason. Anyway, since you were very broad with what you were building (a simple RPG), this answer will suffice. If you are more specific on what you need all these threads for, maybe then we can give a better solution.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lcass
« Reply #10 - Posted 2013-12-26 14:26:09 »

Multi threading is useful for large tasks that would hold back the rest of your program. If you are going to use it you need to make sure that the threads that rely on each other are coordinated so. You will also need to make sure they are not created when you make an object such as creating a new thread when you make a player this can overload your computer and is a common mistake with threading.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (34 views)
2014-07-23 21:16:32

Riven (22 views)
2014-07-23 21:07:15

Riven (25 views)
2014-07-23 20:56:16

ctomni231 (56 views)
2014-07-18 06:55:21

Zero Volt (48 views)
2014-07-17 23:47:54

danieldean (39 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!