So, I've been working on my network stack, and it occured to me to wonder whether there're any real advantages to running the networking in its own thread. If I use nonblocking threads and pump the network stack every tick, I'm beginning to suspect that would be actually MORE efficient than keeping a thread around that just spent 90% of its time blocking on I/O and another 9% of its time waiting for mutexes to unlock. It's not an issue of leaving processors idle; there're lots of other tasks I can assign processors to. The particle engine, for instance, could happily consume a couple of extra processors. Does anyone know of any compelling reason to use blocking sockets and a seperate thread instead of nonblocking sockets? Is there a danger of overflowing packets? Is there some hidden cost in the operating system? Is it just cleaner?

Hi,

What OS are you on? If you're using Winsock, you can take a look at Alertable I/O, that's the Write/ReadFileEx functions... basically, you let the system manage the dirty stuff, however it's a scatter-and-gather method. Try looking at I/O completion ports also... the win2k and winXp kernel have made it a little easier to use... but again, you let the system manage the thread pools, this is good if you're writing a server... other than that, I don't see an issue with what you're doing... if you're happy with the performance that is... you are polling after all, and you can use the synch object that windows provides if you're running on windows...
chhers

If you are running a program on a system with just 1 CPU, introducing threading in that application won't increase execution speed of the program (in fact it is even reduced because threading introduces context switching overhead).

If you are running a program on a multiprocessor system, having a thread for each CPU of that system allows to use all available computational resources.

Threading is useful in cases, where a task needs to block. One example may be a networking thread that is receiving network packets. Allowing this thread to block allows for an easier implementation, only the part where the data is transferred from the networking thread to the application needs to be synchronized.

Threading also allows for a better partition of available CPU-time. Consider the case of a GUI-thread and a CPU-bound thread. If the CPU-thread runs with a lower priority than the GUI-thread, the application will be responsive to user input while still maxing out CPU usage.


In your particular case you have two options:
1) Use nonblocking I/O with just ONE (main) thread.
2) Use a network thread besides your main thread.

If you are sending your packets in a fire-and-forget manner (like UDP), then option 1) would be fine. You won't need another thread besides the main one, so you don't have to synchronize and you don't have context switching overhead. (If you are sending packets too fast, some will get lost. But that happens anyways.)

However, receiving packets from the network is easier when having a second thread that blocks until a packet is available. So you may want to have a thread for receiving packets (but not for sending them).

I have always recommended AGAINST putting network I/O in its own thread, for much the reasons you're suggesting. It's even mentioned in the Forum FAQ :-)