[MUD-Dev] [TECH] Server Bottlenecks

[Eamonn O'Brien]

Maybe this is a dumb question but why do you need all those threads? 
In fact why do people use huge amounts of threads at all for MMO
games? I always thought that threads had the greatest utility when
tasks could run in parallel with very little inter task
interaction. An MMO game is riddled with inter task interaction,
since presumably every single player can interact with every other
player, or object in the game at any time. This means you have to
take huge amounts of care to make sure you do not have threads
stomping all over each other, corrupting your game state. Other than
that I would imagine the only place that threads were nescessary
would be for any blocking tasks (gethostbyname or similar calls)
that would cause the whole game to lag or if you are going to be
using multiprocessor servers everywhere. And even then I would
imagine it would be easier to run 4 servers on a 4 processer
machine, than to run one huge server (what do MMOs use for servers
these days anyway?). By multithreading code you end up with a lot of
messy bugs, especially the non-deterministic sort where you thrash
memory in one place while accessing it in another, all those threads
also take up extra memory, and cpu time switching between them. With
several thousand threads you would need to be careful that you do
not allocate any large blocks on the stack, if those thread stacks
grow to even about 64k then you are using over 300 megs of memory
just for your stacks.

The only bug that multiple threads really protects against is the
dreaded infinite loop, but if that can happen you will probably be
in trouble anyway, even one or two threads looping on a processor
can give it a nasty performance hit. Single threaded designs have
always struck me as being much cleaner in so many ways, I was just
wondering why the current standard for MMOs seems to be
multithreaded, Is there some benefit I am missing? For the record I
have developed some highly multithreaded stuff (in Java) but it was
middleware with a very clean Input->DatabaseAccess->Output sort of
structure, where it was easy to have input threads, which dumped
objects to a database queue, which dumped results to an output queue
and so on, because the database access tended to block a lot,
multiple threads were needed. Presumably any sort of game save, on
an MMO game works like muds, periodic save, load on enter game, save
on exit game. So if you really wanted I could see a use for a game
save thread or whatever (players save tick comes up, move them out
of the game thread and into a save thread, do the save which may
take a couple of seconds, then flick em back into the game).

Why do you need 2 threads per player? Your socket code is presumably
already multithreaded, so a reader/writer thread would seem
redundant, I am also guessing there is one thread for the player in
game which means everything needs to be synchronized, with mutexes,
semaphores etc everywhere. Even using new and delete can become a
major bottleneck with multiple threads. Every malloc could end up
blocking until whichever other thread had the memory access
semaphore gets around to freeing it (though obviously you could work
around this in various ways).

So the question basically is this, "What is the major advantage of
highly multithreaded design that I am missing out on?". The mud I am
developing on at present (Fox MUD) is a merc derivitave, 2 threads,
one for gethostbyname, everything else in the other thread, and
while some things are awkward, I cannot believe that having the same
design in a multithread implementation would be better.

And finally, why are so many people still using fork/exec, look at
pthreads which are available on linux and do the same only much much
better, (pthreads or posix threads run in the same memory space, so
you dont need any shared memory sections etc, they also start/stop
without the big performance hiccup that fork/exec can have, much
more like the windows threading model).

Thanks all,

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