I''ve heard/read several times that using lots of threads in bad On boot my system has 274 thread on 36 processes. How could it possibly matter is I use 1,2, or even 20 threads!

Lots is a matter of opinion....

From memory the recommendations were not to exceed 50 on 9x or 500 on NT.

If you need more that those numbers consider using an execution queue and worker threads.

I''ve gone with the worker thread model so I''m probably going to be limited to just a few. I have one thread for graphics, another for the main loop. So far I can see any good reason to use more that that. Originally I was keen on having one for input, another for networking etc. In the end however you should spend some time thinking about when the data -needs- to be processed by. I was going to use the threads to get the networking data early but as I process all data in order (get input\network then process, I went back to a single threaded model. Then I notices that my interface would hang during long processing items(loading levels etc). Since then i have seperated the graphics system from the main loop. I may consider having a small pool of worker threads where i can submit large processor intensive tasks like level loads(building quadtrees), file operations...etc. That way i can have a responsive interface wile doing intensive tasks.

As for the the thought of using threads for each ai I''m steering against it. I don''t wish of limit myself to the constraints of the most restrictive OS so I''m avoiding the headache.

HTH

gimp

In my experience, there's really no need for threads in serious game development. The only practical case I can see is using them for processing windows messages so timings on keyboard input/etc are a bit more accurate. However, all windows messages have a timestamp on them so there's really no need.

The reason I'm mostly opposed to using threads for game development is because it adds needless complexity to an already complex system. Synchronization issues and data hazard problems could conceivable make it a mess.

It might be an interesting experiment to try playing with a highly threaded game, but I really can't conceive of a serious reason to use them.

Edited by - daveb on November 12, 2000 2:12:01 AM

If using threads made the code harder I wouldn''t want to use them either.

This is windowed, not in full-screen:

I''m currently using 4 threads, and it made it easier...
one handles window msgs,
one is the main loop, get input & render (previously it would hang when you clicked on a menu item!)
one is for client communications
the last is for server communications

(every client is also server, much like gnutellanet)

If you''re using non-blocking sockets (which I''d highly recommend), there''s no need for threading. The amount of time it takes to do a select() and a recv()/recvfrom() is negligible. Just process all your sockets at the beginning of a frame and you should have no problems.

You''ll still need to seperate your interface from whats going on underneath. The alternative is to segment large tasks in to smaller bits to ensure that a complex task like getting a server list or loading\decompressing a 5m zip file doesn''t make the app unresponsive. This however is a fair bit uglier than it seems as you have to work on syncronising frame to frame tasks. I use two threads, interface and main loop. The main loop runs to a schedule of X milliseconds, the interface uses whatever CPU time is left.

I use blocking sockets and just check every connected socket in the main loop. I also use SDL to provide me with window events on things that happened, all this input is run through a pluggable factory that work out what to do with it. Doing it this way allows me a fair amount of freedom when it comes to threading as if I ever wanted to go back to a worker thread model it would be much easier

The tough cookie seems to be graphics. Updating an objects position \ drawing that same object require an internal mutex lock on the object to ensure your never trying to read the objects location(to draw) at the same time the movement system is updating the position. This means lots of locks\unlocks.

Ugh. That sounds pretty ugly. Why not keep it simple and have a game that looks like :

while(!game_done){   process_network_sockets();   process_interface();   process_game_stuff();   render_game_stuff();   flip();} 

Trivial, simple, and robust.