Threading in C++

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
Jach
Posts: 167
Joined: Sat May 05, 2007 8:38 pm UTC
Contact:

Threading in C++

Postby Jach » Mon Jul 30, 2007 1:09 am UTC

So I'm in a group and we're in the process of planning out a game, and one of them wants to use C++ because of its threading (does Python have threading? I'm too tired to go researching). I'm not familiar with it (and I had thought it was only for multi-cores), so I'm wondering what the real benefits and downsides are, and if it's really machine specific. He's just learning about it, which makes me more hesitant to give my vote for it, but he seems to think it'd be cool. I think it'd be an unnecessary complication to the programming part, with no real speed benefits, so I'm just saying we'd be fine with proper OOP which he doesn't fully understand yet.
I love reading quotes.

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: Threading in C++

Postby yy2bggggs » Mon Jul 30, 2007 1:39 am UTC

Kind of hard to say, since C++ has no threading. Which means, obviously, the threading he is talking about isn't C++ threading. Which also means there's more relevant information that we're missing.

If you're looking for portability, POSIX threads are fairly common.

What's the target OS? What's the target audience?

User avatar
Torn Apart By Dingos
Posts: 817
Joined: Thu Aug 03, 2006 2:27 am UTC

Postby Torn Apart By Dingos » Mon Jul 30, 2007 1:46 am UTC

Python has threads in its standard library.

User avatar
Jach
Posts: 167
Joined: Sat May 05, 2007 8:38 pm UTC
Contact:

Postby Jach » Mon Jul 30, 2007 2:07 am UTC

Target OS is Windows, audience is the average Windows n00b.

And I think he wanted to use something like Zthreads to do threading.

Yay, I just noticed the small threads section in the Python documentation...
I love reading quotes.

Rysto
Posts: 1460
Joined: Wed Mar 21, 2007 4:07 am UTC

Postby Rysto » Mon Jul 30, 2007 2:54 am UTC

It's impossible to say whether threading will make your program more or less complicated without taking your design into consideration. It depends heavily on what you're trying to do.

I will say that threading will bring a lot of complications to any program, so if you can reasonably avoid it, do so. You have to keep a whole new set of issues in mind at all points while you're programming, and if you're unfamiliar with threading, it can be a long and frustrating experience dealing with bugs.

zenten
Posts: 3799
Joined: Fri Jun 22, 2007 7:42 am UTC
Location: Ottawa, Canada

Postby zenten » Mon Jul 30, 2007 3:12 am UTC

Well, you could use it if you have one program that has elements that work largely independent of each other (but still have to communicate enough that they aren't just separate programs). But yeah, don't use it unless you need it.

priapus
Posts: 73
Joined: Mon Jul 23, 2007 3:23 am UTC

Postby priapus » Mon Jul 30, 2007 3:21 am UTC

..
Last edited by priapus on Mon Aug 20, 2007 6:39 am UTC, edited 1 time in total.

User avatar
taggedunion
Posts: 146
Joined: Fri Jul 06, 2007 6:20 am UTC
Location: BEHIND YOU

Postby taggedunion » Mon Jul 30, 2007 5:59 am UTC

Eh, I'd stay away from multi-threading. At least, stay away from it for now. If you wish, add it as an extra/bonus feature after all the other logic is done and solid.

I will take this chance to say that threads are a basic type in Lua. :) So, who knows, Lua might turn out cool.
Yo tengo un gato en mis pantelones.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Postby EvanED » Mon Jul 30, 2007 6:06 am UTC

Rysto wrote:It's impossible to say whether threading will make your program more or less complicated without taking your design into consideration. It depends heavily on what you're trying to do.


I wouldn't say that.

I can almost guarantee that multithreading will make your program more complicated, no matter what the language. That said, if you want to program in the future, you WILL be doing multithreaded programs, at least until someone comes up with a model of parallelism that works better. (Okay, this is a bold statement, and I shouldn't say it exactly as I did. However, performance critical code into the future is going to need to be parallel, because singlethreaded performance is increasing slower and slower.)

Multithreading in some sense comes into its own when you have multiprocessors (including multicores) because each CPU can run a thread at the same time. Depending on your application and how well you can parallelize, that could theoretically produce a 2x speedup with dual cores, 4x with quad, etc.

But this is not its only use; it's also important with a fairly large class of programs on single cores. It's one way that you can get increased responsiveness in your program. For instance, many years ago I wrote a program that draws Mandelbrot and Julia sets. (The idea was to expand it to other fractals, but it sort of died.) Calculating the fractal took about 10 seconds, and it would do it when the program first started then whenever the window was resized. During that time you couldn't even hit the X to close the program (unless you wanted to force quit) because the program was busy calculating the fractal and so couldn't respond to the WM_QUIT message that Windows was trying to send it. I rewrote a bit of the program to use multiple threads -- the main thread would kick off the calculation thread in the background, which would then go and actually do the hard part, then report back to the GUI thread when it was done so it could copy the bitmap the worker thread made to the screen. Now you could use menus, resize the window, close the program, whatever before the fractal was drawn.

Any time you have semi-independent tasks, it's possible that breaking them up into threads is a reasonable choice. For instance, Word runs it's spell checker in another thread. Games might run physics, rendering, AI, and collision detection all in different threads.

(I should say that, at least under Windows (I have no clue about programming under X), threads are not the only way to achieve this effect. I could have also used PeekMessage in the fractal calculation. However, I doubt this method scales nicely if you start having a bunch of different tasks that you need to perform, because you need to insert such a call into each of them. However, it is somewhat of a middle ground which removes a lot of the difficulties in multithreaded programming but doesn't give you all of the benefits.)

priapus wrote:multi-threading will almost always make your application more complicated. If it's a simple game (ie, not online), I suggest using events instead of threads.


Events and threads are orthogonal issues. You can have a single-threaded, event-driven program, or a multi-threaded event-driven program, or either of the other combinations.

taggedunion wrote:Eh, I'd stay away from multi-threading. At least, stay away from it for now. If you wish, add it as an extra/bonus feature after all the other logic is done and solid.


This smells to me like a bad idea, at least depending on how you look at it. I have to confess to a lack of real-world experience, but parallelism isn't something you just retrofit onboard. If you choose to go this route, don't think it will be anywhere near just a matter of "hey, let's add threads now"; doing it effectively will probably require either up-front planning in the architecture design, or a LOT of work when you actually do it.

This isn't necessarily saying you SHOULDN'T just get a single-threaded version going at first, I'm just saying beware that this isn't something you just add in later. (Except for a small class of programs. My fractal generator was pretty easy to do once I learned that most MFC classes aren't actually threadsafe for instance. But that's because there was almost no communication between the GUI thread and the worker thread. Something like physics + AI + collision detection probably has a lot more.)

Also, for C++, Boost has a threading library. Boost stuff tends to be of the highest quality, so you might want to look into that.

priapus
Posts: 73
Joined: Mon Jul 23, 2007 3:23 am UTC

Postby priapus » Mon Jul 30, 2007 7:24 am UTC

..
Last edited by priapus on Mon Aug 20, 2007 6:39 am UTC, edited 1 time in total.

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Postby yy2bggggs » Mon Jul 30, 2007 7:48 am UTC

EvanED wrote:Also, for C++, Boost has a threading library. Boost stuff tends to be of the highest quality, so you might want to look into that.

I wouldn't go that far. Certain pieces of boost are high quality, but there are those annoying little bits here and there that prevent me from saying that it tends to be of highest quality.

In addition, I wouldn't push threads or "just the event driven approach" one way or the other. What is appropriate depends on what you are doing.

You can make your program responsive without using threads, and I have made this work easily enough in a high performance program. The main thing that made it easy was that the tasks could be segregated into tiny "atoms". The main thing that made this approach favorable to threads was that I needed to essentially write my own scheduler to throttle overall CPU usage, and the subtasks I was performing weren't time critical. (Full disclosure--this application was multithreaded, but that was for a different reason).

For simpler games, "threads are hard to get right" could very well be a legitimate motivation not to use threads. It just depends on what you are doing.

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Postby davean » Mon Jul 30, 2007 10:13 am UTC

EvanED wrote:(I should say that, at least under Windows (I have no clue about programming under X), threads are not the only way to achieve this effect. I could have also used PeekMessage in the fractal calculation. However, I doubt this method scales nicely if you start having a bunch of different tasks that you need to perform, because you need to insert such a call into each of them. However, it is somewhat of a middle ground which removes a lot of the difficulties in multithreaded programming but doesn't give you all of the benefits.)


There exists a better way, acheviable by inverting the structure you describe. Instead of inserting the PeakMessage into the tasks, insert the tasks into the peek messages. Code each task as a state machine holding the entire state in a data structure and have a top level loop like:

Code: Select all

queue TaskQueue
loop:
    PeekMessage
    task = TaskQueue.pop
    partially compute(task)
    TaskQueue.push(task)


On a side note, it is generally trivial to write a parallel program from scratch if one takes a modicum of care to list the nature of each shared components parallel requirements. Bad wording, what I mean is the preconditions of a proper call. With those properly understood aligning the computation between threads is a trivial matter.

That said, adding it with about any amount of existing code is a task usually significantly more daunting then throwing away everything you have. The number of bugs introduced in this manner is astounding.

Threaded programming requires proper accounting one can often skip in single threaded programs. Very easy accounting to put in place from the start, but backtracking and determining the restrictions and nature of existing code is basically reverse engineering and denies you the opportunity to decide on proper semantics such that you get a sane structure that you can work with reliably.

User avatar
Jach
Posts: 167
Joined: Sat May 05, 2007 8:38 pm UTC
Contact:

Postby Jach » Mon Jul 30, 2007 10:05 pm UTC

Okay, lots of arguments for threading. The particular game idea is sort of a MMO game in a 2D world with different maps (think Furcadia or Dofus), and it would query an online database for the information it needs. I wouldn't think querying would be that intensive except on the server, because I can get about 680 per second on this old computer (though online I don't know). I'm still playing with the idea of doing it directly in the program, or querying a script on that site to do the information-sensitive work like connecting to the database, and which would either just return the database connection or do all the MySQL stuff itself and return the results.

I could see the use in threading by setting the loading of the map into a background process, and either load it in such a way that they can still start playing on it while it's loading, or have a loading bar. But the images in the best-case scenario would be included with the game, so the overhead of downloading from somewhere would be gone.
I love reading quotes.

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Postby davean » Mon Jul 30, 2007 11:25 pm UTC

Jach wrote:Okay, lots of arguments for threading. The particular game idea is sort of a MMO game in a 2D world with different maps (think Furcadia or Dofus), and it would query an online database for the information it needs. I wouldn't think querying would be that intensive except on the server, because I can get about 680 per second on this old computer (though online I don't know). I'm still playing with the idea of doing it directly in the program, or querying a script on that site to do the information-sensitive work like connecting to the database, and which would either just return the database connection or do all the MySQL stuff itself and return the results.

I could see the use in threading by setting the loading of the map into a background process, and either load it in such a way that they can still start playing on it while it's loading, or have a loading bar. But the images in the best-case scenario would be included with the game, so the overhead of downloading from somewhere would be gone.


You can't return a MySQL connector remotely. And, 680 won't last if you go out of mem or start writing.

I think you might not be ready for this project given what you seem to know.

User avatar
Jach
Posts: 167
Joined: Sat May 05, 2007 8:38 pm UTC
Contact:

Postby Jach » Tue Jul 31, 2007 7:22 am UTC

Which is why I see it as a great learning experience, if it ever gets off the ground.
I love reading quotes.

User avatar
evilbeanfiend
Posts: 2650
Joined: Tue Mar 13, 2007 7:05 am UTC
Location: the old world

Postby evilbeanfiend » Tue Jul 31, 2007 9:13 am UTC

Jach wrote:Which is why I see it as a great learning experience, if it ever gets off the ground.


what experience does your group have? it sounds like you are new to this sort of thing so you may be better off starting by reimplementing a classic game like tetris or pacman, its harder than it sounds ;)
in ur beanz makin u eveel

User avatar
Jach
Posts: 167
Joined: Sat May 05, 2007 8:38 pm UTC
Contact:

Postby Jach » Tue Jul 31, 2007 11:02 am UTC

I've already done a Tetris clone, using very poor graphics. =P I'm currently working on an EyeQ clone which will have stuff from Brain Age as well (hence my question about maze generating), because it looks neat but I don't want to shell out any cash. A side-scroller is at the back of my mind, I just need to look at some more examples like Barbie Seahorse Adventures. My problem is I'm lazy.

So yeah, I do realize how much effort games take. I've had no experience in the realm of communicating online or through a network from a regular application, I've never done anything with threads, and I've done very little with C++ because I haven't needed to. Now I'll probably need to, it's a good chance to learn at least. As for the group, they probably have more experience in C++ and Java, but I have more experience overall and in higher languages, and I'll be really learning C++ later on this fall. Apart from Java, I've been sticking with higher level languages, which might be good or bad depending who you talk to.

Since there seem to be Threaders here, what would be some more uses that would greatly enhance the performance of something like an MMO?
I love reading quotes.

Mask of Destiny
Posts: 11
Joined: Thu Jul 26, 2007 9:43 pm UTC
Location: CT, USA
Contact:

Postby Mask of Destiny » Tue Jul 31, 2007 3:25 pm UTC

Torn Apart By Dingos wrote:Python has threads in its standard library.

But they're usless for taking advantage of multiple cores or processors because of the global interpretter lock. If that's not your goal than they're just fine.

EvanED wrote:I can almost guarantee that multithreading will make your program more complicated, no matter what the language. That said, if you want to program in the future, you WILL be doing multithreaded programs, at least until someone comes up with a model of parallelism that works better.

There are already languages that can handle parallelism without using the thread model. Erlang and certain dataflow languages are designed to address this problem specifically and some other languages have auto-parallelizing implementations (Haskell, Fortran). Presumably, they're not suitable for achieving good parallel performance in all cases otherwise they'd be used more often.

Anyway, to return to the original question, I would say that unless you're trying to take advanage of multi-core/multi-processor hardware most game code can probably be single-threaded without it being a problem from a user's perspective. The only real exceptions are networking code. It's possible to handle BSD sockets cleanly without using threads, but threads are usually easier to use in this context.

If everything the client needs can be handled directly my MySQL then you might be able to get away with having the game clients connect directly to the MySQL server and avoid writing any network code at all. You can't return a MySQL connection remotely, but you can make remote connections if the privileges are set up properly.

PlayerOne
Posts: 14
Joined: Tue Jul 31, 2007 12:41 am UTC

Postby PlayerOne » Tue Jul 31, 2007 7:40 pm UTC

If you need threads in C++, I strongly recommend getting a recent compiler (recent versions of Gcc, or MSVC 7.1+), and using boost::threads. The discussions on the concurrency mechanisms in C++0x (the latest revision of the standard, due in 09) seem to indicate that Boost Threads will be used as a base for the standard library's support of threading (albeit with a few changes). That to me is a fair indicator of the quality of the library.

I also strongly recommend using your recent compiler to use std::tr1, the extensions to the standard library proposed in Technical Report 1. These will enter the standard library proper in the next standard, and offer many great improvements to C++ (notably bound functors, that make it possible to easily define type-safe callbacks). If your standard library doesn't support std::tr1 yet, you can use Boost TR1, which will look at your system's standard library and import Boost equivalence namespaces into std::tr1 if your library doesn't offer some TR1 features. When the system starts better supporting TR1, Boost will just let the system take over, transparently for your apps.

As for python, the standard interpreter (CPython) does have a global interpreter lock, which makes it a multithreaded but monocore implementation, with no real concurrency. However, the language itself has no such limitations, and I wouldn't be surprised if Jython or IronPython just used the underlying VM/CLR facilities for threading to get real concurrency.

I'd also like to point out that there are games out there written in pure python, and on modern machines it is very possible to get a good framerate with such a language, and in a fraction of the development time that you'd have for from-scratch C++. Unless of course you're planning on writing Doom 4, in which case you need all the spare cycles you can get.

And I'd like to conclude by echoing the thoughts of the crowd here: multithreading is a very sharp knife disguised as a lollipop. Especially in C++, where it is very very easy to miss something and have threads stepping over each other's data. If you really must use threads, prefer to use them for tasks that do not require frequent access to concurrent data, and can run completely independantly from the rest of the game. For instance, you might have a thread that is solely in charge of playing background music. Its only communication path with the rest of the application is a thread-safe queue, where filenames to play are pushed by the rest of the app. The music thread pops a filename, opens it and starts playback. Very little interaction with the application at large, and a very tightly controlled communication pipe with the rest of the program.

In general though, and eventloop based model works for 95% of the tasks a game requires. The other 5% is low impact stuff that can be fired and forgotten, and it might make sense to spin up a thread to carry out that stuff in parallel with the main event loop.

But remember: sharp knife disguised as a lollipop.

iw
Posts: 150
Joined: Tue Jan 30, 2007 3:58 am UTC

Postby iw » Wed Aug 01, 2007 8:05 pm UTC

Check out the amazing SDL library: it gives you event loops, threading, image utilities, ways to interface with OpenGL (and I think DirectX), and as a bonus, your program will be easier to port to other operating systems. It's a C library, but it works with C++ natively and there are bindings for Python, Haskell, and pretty much every popular language (Ada, C#, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, and Smalltalk).

User avatar
Jach
Posts: 167
Joined: Sat May 05, 2007 8:38 pm UTC
Contact:

Postby Jach » Wed Aug 01, 2007 8:26 pm UTC

Okay, here's what my friend is thinking about threading. To me it mostly seems like a really, really bad idea, since I prefer MySQL databases when I have them. (Hmm, a giant array, even if was a dictionary, seems very silly.)

Going back to the threading-way-of-thinking, I already have a pretty good idea of how I'd write the server daemon. Well, a basic idea anyway, but I'm pretty sure I know how I'd work the threading anyway. I already knew that I don't want two threads trying to change the same thing at the same time, so I kinda figured it this way:

Main thread spawns a thread that listens for connections, and another one to keep track of information about each player, perhaps in a multidimensional array... or via objects (duh, I still don't quite have object-oriented thinking down yet) and store these objects in a vector or something, just to keep track of them in some way. Listening thread detects a connection, spawns a new thread dedicated to maintaining connection and keeping track of data on that specific player. These individual threads either are referenced from whatever thread keeps track of player information together (say, an online list), or they simply set the variables that the tracking thread reads when it updates the list or whatever.

It just seems like more work than it's worth, and seems like it'd be horribly inefficient compared to just running SELECT and UPDATE queries on the database.

Edit: And yes, I love the SDL. We'll be using that, once we agree on a language to use.
I love reading quotes.

User avatar
AquaFox
Posts: 24
Joined: Tue Jul 31, 2007 3:49 pm UTC
Location: Oman
Contact:

Postby AquaFox » Wed Aug 01, 2007 8:47 pm UTC

http://www.boost.org/doc/html/thread.html

Boost.Threads for the win. Anything Boost for the win actually.

iw
Posts: 150
Joined: Tue Jan 30, 2007 3:58 am UTC

Postby iw » Thu Aug 02, 2007 5:47 am UTC

Jach wrote:Okay, here's what my friend is thinking about threading. To me it mostly seems like a really, really bad idea, since I prefer MySQL databases when I have them. (Hmm, a giant array, even if was a dictionary, seems very silly.)

Actually, if you were going to go that way, using MySQL would be quite silly, as keeping your stuff on disk will actually slow you down - you want the database in memory. And what is a dictionary but a poor man's index to a database? It doesn't sound like you really need the benefits of a full-blown database; a dictionary in memory protected by mutexes should be perfectly fine. (You can use MySQL databases that don't write to disk, but you're still talking to it across a socket, which takes time and has the MySQL overhead.)

Secondly, why have a thread running just to "keep track of information?" Threads share memory; you just need to have your listening thread and your client threads, and each thread can update the global information using mutexes:

Code: Select all

acquire_lock(player_stats_lock);
player.x.whatever = HIGH_SCORE;
release_lock(player_stats_lock);

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Postby davean » Thu Aug 02, 2007 7:26 pm UTC

Jach wrote:It just seems like more work than it's worth, and seems like it'd be horribly inefficient compared to just running SELECT and UPDATE queries on the database.


You clearly have *no idea* what a SELECT or an UPDATE call's execution look like. There is the parsing, then the compiling and optimization, tens of thousands of operations later it *starts* running virtual opcodes in an interpreter with disk seeks and consistent commits.

DB calls are some of the most expensive operations you can ever do.

User avatar
Jach
Posts: 167
Joined: Sat May 05, 2007 8:38 pm UTC
Contact:

Postby Jach » Thu Aug 02, 2007 9:02 pm UTC

Looks like I've been tricked by MySQL reporting the speed at which it executes the queries. >.>; But yeah, what you two are saying makes sense. I guess we might use arrays and keep the database for handling login and stuff that's not performance critical.
I love reading quotes.

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Postby davean » Fri Aug 03, 2007 12:39 am UTC

Jach wrote:Looks like I've been tricked by MySQL reporting the speed at which it executes the queries. >.>; But yeah, what you two are saying makes sense. I guess we might use arrays and keep the database for handling login and stuff that's not performance critical.


Or maybe you lack a sense of the speed any other operation occurs at. Say your database returns a result in 2ms, ok, thats pretty fast for you, only thats 2 ms, you can only do 500 of those a second. Try looking at another operation, say setting a value in an array. Thats somewhere around a ns (depending on processor and other factors). You can do 1000000000 of those a second (actually more). See a difference?

You'll need to do a lot more then 500 loads and stores a second to accomplish much.

paranoid_one
Posts: 9
Joined: Fri Aug 31, 2007 2:43 am UTC
Contact:

Postby paranoid_one » Fri Aug 31, 2007 4:32 am UTC

i was always using pthread for dealing with threads. works under all platforms.

User avatar
colfax
Posts: 15
Joined: Wed Aug 29, 2007 6:00 am UTC

Postby colfax » Fri Aug 31, 2007 5:44 am UTC

I've done several simple multi-player games in the past, and I will tell you that you are going to need to write a multi-threaded server. It is possible to write a single threaded one, but much more difficult.

The standard model for client-server communication from the server side is to have a main thread which listens for incoming connections on the server port. When a connection is received, it spawns a new thread with the new connections information. This thread then handles the communication and logic with that particular client.

As far as persistent data (kept between logins) is concerned. The best way I have found to do it is to load the object at thread creation time, maintain it in the program, and write it back out at termination. This saves you a lot of time and server muscle.

The client is a whole other beast. It sounds like single threaded with a standard game loop would be more then enough for your needs.
~Colfax

"Computer Science is no more about computers than astronomy is about telescopes."
-Edsger W. Dijkstra

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Postby davean » Fri Aug 31, 2007 5:35 pm UTC

colfax wrote:I've done several simple multi-player games in the past, and I will tell you that you are going to need to write a multi-threaded server. It is possible to write a single threaded one, but much more difficult.


Depends on how you think about things, I'll my code is trending towards threaded-event-based. I just find that easier. It has the bonus of being fairly efficient and scaling well.

User avatar
colfax
Posts: 15
Joined: Wed Aug 29, 2007 6:00 am UTC

Postby colfax » Fri Aug 31, 2007 9:46 pm UTC

davean wrote:Depends on how you think about things, I'll my code is trending towards threaded-event-based. I just find that easier. It has the bonus of being fairly efficient and scaling well.


I don't suppose you'd have a link to a paper on doing things that way, I've never really seen it executed well and I'm always looking to learn better ways of doing things.

Thanks
~Colfax



"Computer Science is no more about computers than astronomy is about telescopes."

-Edsger W. Dijkstra

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Postby davean » Mon Sep 03, 2007 4:54 am UTC

colfax wrote:
davean wrote:Depends on how you think about things, I'll my code is trending towards threaded-event-based. I just find that easier. It has the bonus of being fairly efficient and scaling well.


I don't suppose you'd have a link to a paper on doing things that way, I've never really seen it executed well and I'm always looking to learn better ways of doing things.

Thanks


Papers? There are a probably a lot, I mean event based is the oldest trick in the book; just build your code around a separate state machines basically. As for threading it, just have a locking plan or use algs that don't need locks (a good solution for a fair bit of code but doesn't work on a lot of them). I probably could dig up a paper, but I don't think anyone bothers to still write about it.

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Postby yy2bggggs » Mon Sep 03, 2007 5:17 am UTC

If you're using TCP/IP for a real-time multiplayer game, then yeah, you want to use threading (as opposed to event driven design; I won't bother discussing fork/exec options). The sole reason for this is that many TCP/IP operations can hang. A multithreaded approach isolates the effects of such operations so that the game itself, and clients which have no such problems, doesn't have to wait for such operations to time out.

For a serious game, you're probably going to want more sophistication than a mere TCP/IP connection. If you implement your own connectivity using something like UDP, event driven approaches aren't bad.

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Postby davean » Mon Sep 03, 2007 5:24 am UTC

yy2bggggs wrote:If you're using TCP/IP for a real-time multiplayer game, then yeah, you want to use threading (as opposed to event driven design; I won't bother discussing fork/exec options). The sole reason for this is that many TCP/IP operations can hang. A multithreaded approach isolates the effects of such operations so that the game itself, and clients which have no such problems, doesn't have to wait for such operations to time out.

For a serious game, you're probably going to want more sophistication than a mere TCP/IP connection. If you implement your own connectivity using something like UDP, event driven approaches aren't bad.


Might as well do with event driven with TCP also, and you know that all those operations blocking is only an option right? Just use the non-blocking option or varieties (depending on preference)

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Postby yy2bggggs » Mon Sep 03, 2007 5:45 am UTC

davean wrote:Might as well do with event driven with TCP also, and you know that all those operations blocking is only an option right? Just use the non-blocking option or varieties (depending on preference)

Yes, I know that configuring blocking is an option. But it's not the problem.

The main failure cases where something hangs that has to time out involve all sorts of combinations of partial connections, partial teardowns, and misbehaving TCP/IP stacks (on your machine or your guests, unless you happen to have a decent stack; note that misbehaving TCP/IP stacks aren't really as rare as you would think). And yes, you can configure various things on your system to minimize the impacts of such hanging, but you can't eliminate it.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 9 guests