[MUD-Dev] [TECH] Server Bottlenecks

[ceo]

Eamonn O'Brien wrote:

> 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.

AFAICS there are several answers, all stemming from the conceptual
simplicity of threads. Some metaphors in computing have turned out
to be terrible (IMHO "window" is a terrible name for what it is...it
took me five years before I realised that might be a deliberate
attempt at a metaphor). Others prove easy to comprehend to large
numbers of poeple, and IME threads is one of these.

Whilst tutoring undergraduate comp-sci students, things like
understanding OOP come up time and time again as an area fraught
with difficulty (mainly due to lecturers/academics who provide
over-simplified or simply bad introductions). I've never had anyone
who didn't understand threads with consumate ease - although there
were a couple who for a while confused threads with physical
processors, mainly because of literature that talks about a thread
"executing code".

So, IMHO this has a huge effect on how, when and where
multi-threading is used. Looking at projects which are largely about
ease (cost) of implementation and maintenance (which ought to be
true of a commercial MMOG, for instance) - and in large-team
projects, often about how easy it is for a newcomer to come up to
speed - then in any situation where "lots of things have to happen
at once" there will be a huge temptation to use threads. Not least
because, conceptually, they have a perfect match with the problem
(at the highest level of abstraction).

Of course, that often leads to bad (even terrible) design. I suspect
that usually threads get chosen by default partly because many teams
these days have no dedicated architects, and hence little
consistent, clear architecture (note: this is a gross
generalization, and vague supposition, so feel free to disagree, but
I won't try to defend the point!).

As an aside, I know academics who still wax lyrical to their
students about the alternatives to threads, and even one who appears
completely unconvinced that threads are ever worth using. Mostly
they don't appreciate that threads are considerably easy to reason
about, but OTOH they do have some good arguments in favour of their
personal favourite.

...and then there's cross-platform concerns. In networking, the
alternatives to thread-per-connection have historically required
significant extra expertise (e.g. clustering etc) or have varied
wildly from platform to platform. These days we have approximately 6
different alternative ways of doing asynchronous/non-blocking
I/O. There is a nice summary of some different fundamental
implementation approaches at Kegel's site:

  http://www.kegel.com/c10k.html#strategies

That's a big page, so here's the relevant section (currently the
fourth link in the table of contents at the top)

   "The following five combinations seem to be popular:

    1. Serve many clients with each thread, and use nonblocking I/O
    and level-triggered readiness notification

    2. Serve many clients with each thread, and use nonblocking I/O
    and readiness change notification

    3. Serve many clients with each server thread, and use
    asynchronous I/O

    4. serve one client with each server thread, and use blocking
    I/O

    5. Build the server code into the kernel"

...but it doesn't cover Windows Completion Ports that well (which
IMHO add some nice new features to the traditional
asynch/non-blocking I/O), and then there's Sun's "New I/O for JAVA"
which is based on select(), but then cherry-picks some of the good
aspects of several other libraries. Unfortunately, even 2.5 years
after release, Sun hasn't documented their API yet, so it's hard to
know exactly how it works and what guarantees it places (e.g. it
would be nice to know whether a select() call is O(N) in the number
of registered connections, or whether it's better than that...).

IMHO, a lot of people use threads in places they shouldn't simply
because they don't know any better, and either don't have the
time/resources or the effort/willpower to learn what they need to
know in addition.

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