Threaded vs. Non-threaded
Author
These are two engine types, you can make it completely non-threaded and have one single main loop going trough it all, using non-blocking calls to api''s etc.
Or you can have a threaded engine with which you can spawn threads for blocking calls or handle generally anything in threads.
What are the pros and cons of these approaches? Which one would you use and why? And is there a best approach?
I personally prefer non-threaded, as it makes things way easier to keep track of. Or that is what I think, anyway. For threads, you have to think somewhat different.
Author
Yes, you have to have mutexes on shared data for instance(If it''s written, things that only read need no mutex)
It has advantages and disadvantages.
I mean, take the networking part: On a threaded engine you can simply spawn a thread with blocking calls to winsock and simply send the data where it needs to go, but on a non-threaded, you do use non-blocking calls, but how much data do you take in each iteration of the engine? (This is my current dilemma), reading one ''packet'' every iteration is too slow.
www.boycott-riaa.com
It has advantages and disadvantages.
I mean, take the networking part: On a threaded engine you can simply spawn a thread with blocking calls to winsock and simply send the data where it needs to go, but on a non-threaded, you do use non-blocking calls, but how much data do you take in each iteration of the engine? (This is my current dilemma), reading one ''packet'' every iteration is too slow.
www.boycott-riaa.com
Using multiple threads doesn''t make the application run any faster (on a system with one processor that is). But an application could be made to be more responsive by using multiple threads, but that isn''t the same thing as being faster.
[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]
[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]
quote:Original post by Siaon
These are two engine types
No there isn''t, you''re imposing an arbitary definition for no real point.
Using only a single thread will leave you struggling when you come to do certain things, like sound or networking. And at the opposite end, using a different thread for everything is going to kill your performance and make the whole thing much less predictable.
In general, stick the minimum number of threads needed to get the job done well.
I agree with the last poster!
Use threads when needed. I hate trying to follow code that uses loads of threads. Use only when it is needed, some people i know seem to use them out of habit.
Use threads when needed. I hate trying to follow code that uses loads of threads. Use only when it is needed, some people i know seem to use them out of habit.
I find that using threads makes debugging more difficult. If you''ve got a thread with a bug, and it trashes memory, the *other* thread might crash, and then you have no idea what''s going on.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
