Re: [AD?] New Java version of CircleMUD

From: Daniel A. Koepke (
Date: 03/27/02

On Sun, 24 Mar 2002, Shay wrote:

> It depends on how you setup the threads and how much you keep static.

Yes and no.  Let's be clear, here.  I'm not saying multithreading is,
across the board, an inferior model.  The parallelism is quite important
in many domains.  Massive parallelism, which is what a thread/connection
truly is, has fewer application domains and, more importantly, is wholly
inappropriate for a great many.  The problems are many and more than can
be reasonably discussed on the Circle list.  We need to consider both the
number of thread contexts and the cost of the context switch.  In the
thread/connection model, the context switch overhead might be low, but the
number of context switches can be problematic (thrashing and
synchronization issues come to mind).

For I/O bound applications -- which a Mud (along with damn near any other
Internet service) is -- we want to exploit concurrency, not parallelism,
and thus multiplexing and not multithreading.  This does NOT mean we
cannot exploit parallelism for parts of our application.  Instead, it
merely suggests that we need to look at different *models* of parallelism
than the naive strategy Java formerly forced people into using.

> I'll admit that not every turn requires computation, but when it comes
> to things like battles, they can be.

The issue is not whether a turn is computationally expensive, but whether
a turn for *every* connection is computationally expensive.  Note that in
setting aside a complete separate context for *each* user, we're saying
that for each I/O cycle in which this thread becomes active it might be
doing something which takes significant time.  If the cost of a context
switch is not a small fraction of the computation time, we start to run
into trouble.

If we're worried that combat calculations will cause latency, then we can
set aside a single thread for those calculations.  In this way, we
eliminate the latency caused by the little bubbles of inactivity between
polling for I/O, sleeping, and processing the combat events.  It's hard,
however, for me to imagine a combat system that is so computationally
expensive that it merits such treatment.  If you're getting noticeable lag
due to combat, you might look for algorithmic improvements before
attempting optimization of any sort (but especially MT, which introduces
separate engineering concerns like synchronization).  If the lag is an
unavoidable consequence of the system's complexity (why is it that
complex?!), then we might consider moving it to a separate thread with
other feasibly expensive operations, such as global event processing.

> Funny, I think C is ugly..

It is, of course, but in a different way than Java.  C is ugly because of
syntactical warts and the preprocessor-fu needed to gain modularity (such
ad-hockery is counterproductive -- I cannot count the number of times my
zone has been broken by such meta-concerns as file organization), but for
a procedural language it's fairly complete.  My biggest problem with Java
is its feature set (although I'm not crazy about its overly verbose
syntax, either; despite how it might seem, I'm not *that* fond of typing).
To put it succinctly, Java feels too much like a neutered C++ for my
tastes (but note that I'm admitting this is subjective; I darest not pass
this opining off as a fair, objective comparison of the languages, nor do
I want to see that topic raised).


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT