[MUD-Dev] Thread Pools (was: Re: TECH: Distributed Muds)

[Scion Altera]

Wednesday, May 23, 2001, 3:44:32 AM, Matt Chatterley wrote:

> A model which would work (hopefully) does occur to me.

>   [Socket connections] - 1 thread per player to read data and pass
>   on
  
>   [Input processing layer] - 1 thread which interprets all player
>   input

>   [Event Handler] - Accepts events from systems, orders and
>   initiatves actions, events, and consequences to keep the
>   In-Character world running.

Why do you need one thread per player? Why not just have one thread
that iterates through the sockets and queues up their input and spits
out their output buffers? As long as this thread doesn't block and
isn't allowed to run wild (I'm running mine at one pulse per 1/8th
second at the moment), it seems to run well enough.

I'm thinking in terms of the hobby mud, of course, rather than a big
fancy graphical MMORPG, and have yet to do any serious load testing on
my game, mind you :)

Even so... one thread per player seems like overkill to me. Not only
does it necessitate thread safety for all your code (thus introducing
uncertainty and various sundry synchronization issues) but there is a
substantial amount of overhead per thread that seems unnecessary.

Branching out from my own current model for a moment, and touching on
something asnellin at san.rr.com mentioned in your quote, what about a
thread pool?

Consider the model where you have a list of sockets that need to be
updated x times every second. Here is a system I am considering:

  o Start off with one thread doing the updating, and keep track of
  the time taken by that thread to do one iteration of the list.

  o If the time taken exceeds a limit, such as 1/8th of a second,
  spawn a new thread and divide the list equally between the original
  thread and the new thread. Ideally, this will cause the execution
  time for each of the two threads to be less than the limit.

  o If the time taken drops below a limit on two threads, have one
  thread die and give its list over to the other one to consolidate
  the pool.

And for the sake of sanity:

  o Kill all threads who have blank lists.

  o Impose a hard limit on the number of threads in the pool.

  o Throttle the threads so they don't spin up too fast and eat too
  much CPU, even if there's only one of them :)

This way if there are zero connections to the game, there are zero
threads updating the connections. The number of threads vs. the number
of connections is fuzzy, and varies based on the machine the program
is running on. My p3 800 might be able to handle fewer threads vs.
connections, while my 486 may very well be up to the top limit in
threads most of the time, trying to keep the update rate high enough.

A good thing to do would be to make the top number of threads and the
desired socket refresh rate to be tweakable numbers, so it could be
optimized based on the capacity of the hardware.

Now that I've actually worked the model out, I think I'm going to go
implement it. Anybody see any glaring omissions/errors? :D

-- Scion

"The secret to creativity is knowing how to hide your sources." --
Albert Einstein

-- scion at apn.dhs.org -- keeler at teleport.com -- ICQ: 1824934 --


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev