Multithreading question...

Started by
5 comments, last by Mike 23 years, 3 months ago
Is there a maximum number of threads a given program should/could have? I''m working on a server and I was thinking about creating a new thread for each connection, but if there were 25 people connected and each one of them could have a few connections then there would be around 50 or so threads. I could be wronge, but that doesn''t seem like a good thing to me. Would it be a better idea to have one thread for each user and have all of the user''s various connections in that one "user" thread? Thank, Mike Useless Code
Advertisement
There is an upper limit, and it''s dictated by your operating system.

I would personally use one thread per connected user, as most software does. Go with your second idea, one thread per user. Why do you have multiple connections? Transmit & receive, I would figure, but I''d think you don''t want to handle these two operations in an separate threads.

BTW, isn''t 25 people a lot? More power to ya, though.



Hi,

quote:Original post by Mike

Is there a maximum number of threads a given program should/could have? I''m working on a server and I was thinking about creating a new thread for each connection, but if there were 25 people connected and each one of them could have a few connections then there would be around 50 or so threads.

There is a maximum of threads on every OS, and sometimes there is
also a limit per process by default (IBM-AIX), but the real questions is how many threads the box you want to use can handle before it is going to its knees.


I could be wronge, but that doesn''t seem like a good thing to me. Would it be a better idea to have one thread for each user and have all of the user''s various connections in that one "user" thread?

I would use something like a thread pool with a maximum size and some sort of task scheduling to get things done. If you could give us some more details, we could give you some better tips.


Thank,
Mike

Useless Code


cu

Peter
HPH
25 users is a lot, and also a bit of exzaduration (that''s not spelled correctly is it...). I was just trying to avoid a response such as "you''ll never have enough connections to worry about".

The multiple connections per user comes into play when files get transferd. One connecion is for info, and the other for files. I intend for the client to be able to atomatically download a level if the client does not already have it while playing the game (it''s a 2D game and the gameplay is rather limited so not much game data is needed, and I therefor don''t think transmitting a file while playing the game will cause much lag as the game is targeted towards lans).

In all honesty this project is just an excersize in nertwork programming and WinSock. I''m not trying to make a good game.
Threads are not free. Even if the OS will let you create 25 or 200 or 2000 threads you probably shouldn''t. At the very least each of those threads needs a stack and that''s a lot of address space to chew up. There is also some cost per thread in the kernel to keep track of them all. Plus if god forbid you ever have to debug a program that has that many threads active at once it''s going to be hell to figure out what they''re all doing.

The typical recommendation is to have on the order of one thread per processor.

-Mike
Generally it''s more efficient to keep your thread count low, though multiple execution contexts can be useful sometimes...

quote:
I could be wronge, but that doesn''t seem like a good thing to me. Would it be a better idea to have one thread for each user and have all of the user''s various connections in that one "user" thread?


Although you''ll never swamp today''s machines by spawning 25 threads, you''ll have to do a bit more work in order to get at shared data safely...

I''d probably go for a two/three thread approach, but that''s just me... I think you should limit the number of threads you create and use round robin updates within the threads to squirt data out of the connections when it''s needed. There''s no need to generate a thread for each connection.

Jans.
Now that I think about it, it would make more sense to have one thread handling network traphic and one thread actually running the application.

I realize that I could use one thread (that''s how I''ve been doing things up to this point), but I want to get away from using WSAAsyncSelect (It just seems to be a bad way to do things) and the windows message pump as a whole. That is the reason for multi-threading.

Thanks for the input.

Useless Code

This topic is closed to new replies.

Advertisement