select() in server
Author
IS it better to use select() and synchronous sockets to make a 2D online game server, rather than many threads per client ?
IS it better to use select() and synchronous sockets to make a 2D online game server, rather than many threads per client ?
Generally, yes. Better yet would be one of io-completion-ports/epoll/kqueue, or a wrapper thereon.
Author
is http://www.codeproject.com/Articles/20066/A-scalable-client-server-using-select-socket-funct#_comments a good base on which to start ?
When I had to choose I went for multiple threads model because most cpus nowadays are multi-core, so a multi-threaded application is more likely to scale better.
When I had to choose I went for multiple threads model because most cpus nowadays are multi-core, so a multi-threaded application is more likely to scale better.
There is no scaling if all you are doing is using threads to implement non-blocking I/O. Now, if you are also processing data in each those threads, well, that's a different story (with its own pros and cons).
[quote name='KnolanCross' timestamp='1350607314' post='4991608']
When I had to choose I went for multiple threads model because most cpus nowadays are multi-core, so a multi-threaded application is more likely to scale better.
There is no scaling if all you are doing is using threads to implement non-blocking I/O. Now, if you are also processing data in each those threads, well, that's a different story (with its own pros and cons).
[/quote]
Well observed.
You should be using a blocking interface along with a timeout (such as set_sock_opt) or a single file descriptor select (in my case) so you can update each thread and also have them in the sleep process most of the time.
If you ever find yourself needing to sleep a thread, you're doing something wrong. You should be using blocking I/O (and other primitives, like condition variables, events, etc,) and be driven by that. If your OS has no native unblocking timers, and you need to step at a fixed rate, it's OK for one thread to use a timeout-wait for blocking primitives to implement that.
If you use thread-per-client for "scaling," exactly what is each of those threads doing? How are you avoiding those threads stepping on each others toes while mutating your world?
If you use thread-per-client for "scaling," exactly what is each of those threads doing? How are you avoiding those threads stepping on each others toes while mutating your world?
If you ever find yourself needing to sleep a thread, you're doing something wrong. You should be using blocking I/O (and other primitives, like condition variables, events, etc,) and be driven by that. If your OS has no native unblocking timers, and you need to step at a fixed rate, it's OK for one thread to use a timeout-wait for blocking primitives to implement that.
If you use thread-per-client for "scaling," exactly what is each of those threads doing? How are you avoiding those threads stepping on each others toes while mutating your world?
By sleep i didn't mean the sleep function, I meant the OS' sleep state.
In my case I had threads to receive info/send updates to clients and threads to update the world state. To avoid running conditions I used a lot of mutexes and a zone approach to filter data (data in a zone could be changed without affecting others). It was indeed pretty annoying to implement it, but I learned a lot. How he will model his world is up to him
By sleep i didn't mean the sleep function, I meant the OS' sleep state.[/quote]
It may be a terminology thing. The way I understand it, a thread enters "sleep" state by calling sleep() or similar functions. This is different from the "blocked" or "wait" state which is when a thread is actually waiting on something else to happen.
Also, if you use mutexes in your threads, you won't actually scale across cores, because your threads will end up serializing on whatever the common data structure is. Thus, you can save memory, CPU overhead, and programming complexity by using select() or non-blocking sockets instead of multiple threads for your networking.
By sleep i didn't mean the sleep function, I meant the OS' sleep state.
It may be a terminology thing. The way I understand it, a thread enters "sleep" state by calling sleep() or similar functions. This is different from the "blocked" or "wait" state which is when a thread is actually waiting on something else to happen.
Also, if you use mutexes in your threads, you won't actually scale across cores, because your threads will end up serializing on whatever the common data structure is. Thus, you can save memory, CPU overhead, and programming complexity by using select() or non-blocking sockets instead of multiple threads for your networking.
[/quote]
Yeah, it is terminology, afaik even the sleep call is an io block state, waiting for the os to "wake" the process, for instance sleep (10) will make your program stay in the wait state for 10 seconds, while a blocking receive will be in wait state until new data arrives. Anyways, I meant that the process would be in a blocking state and would not consume CPU.
About the mutexes I can see your point but I respectfully disagree.
Mutexes are not active wait, in other words when you reach a locked mutex, your thread enter a wait state, thus it won't consume cpu. In my case, although I had some threads locked in the same mutexes, there were others that were not. So I was using the multiple CPU cores at the same time, this is a huge gain in performance.
There is, of course, an increase use of memory and there is an overhead for the scheduler (since there were multiple threads).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
