[MUD-Dev] Question about threads.

[Nathan F. Yospe]

J C Lawrence <claw at kanga.nu> said:
> On Wed, 13 Feb 2002 13:05:05 -0600 
> David Anderson <Anderson> wrote:

> In essence there are three uses for threads:
 
>   1) Minimising blocking operations
>   2) Easier/more deterministic in-game state transitions 
>   3) Scalability 

> The typical first case for #1 is gethostby{addr|name}() which has
> a long timeout associated with it which can't be trivially worked
> around.  If you don't do (reverse) lookups this is not a problem.

> The more simple case for #1 also impacts #2: keeping your internal
> game state logically consistent.  The base problem is time
> management.  In a typical text mud setup you have a heartbeat loop
> that does a sweep of the active objects on each beat and invokes
> the appropriate code for any state changes needed.  While horribly
> inefficient, this works for small systems and light weight state
> changes.  The problem enters when either:

>   a) The number of state changes to perform on a given sweep
>   becomes large such that the total time required for the sweep
>   grows and becomes unpleasantly noticeable by the users.

>   b) One of the component state change functions executed during a
>   sweep runs excessively long (which leads back into #a).

<snip on fibers>

> A threaded approach can be taken where state change functions are
> executed by distinct threads at some level of parallelism.  The
> fundamental change from the fibre model is that the scheduler is
> pre-emptive.

>   The question of whether scheduling is handled in-application or
>   by the OS is largely moot as it doesn't change (outside of
>   hinting) the base problems.  The real gain that moving to an
>   external scheduler gives you (outside of code simplicity) is
>   that you can now take advantage of multi-processor systems (and
>   possibly distributed systems as well).

There's another advantage, in terms of design.  It's easier to
create parallel stacks on an event loop, and (as a result) can allow
stack paring (e.g. skipping redundant tests and updates) when things
get highly loaded.  Of course, that's assuming the scheduler is nice
to you...
 
> However the big gain from threading is scalability.  The single
> threaded approach dictates that all the state change functions for
> a given sweep be executed sequentially.  Outside of hardware
> contraints the processing of player commands (for instance) need
> not wait on and need not be paced by the processing and execution
> of state change functions and the relative processing of state
> change functions can be balanced such that some degree of fairness
> is achieved between fast and slow state change functions while
> also maintaining a good user experience.

Ah, yes, there's that same advantage, in a different guise.  I would
postulate that having the ability to (also) spawn off an assortment
of asynchronous processes with wrapped descriptors, such that the
server could be spread across multiple hosts, is equally important
for scalability in the long run.

> Please note that threading is not a magic bullet.  Its not.  Its a
> tool that brings its own problems with it with the primary problem
> being data access sequencing and lock management.  Both can easily
> and rapidly become non-trivial problems (do some searches on ACID
> (in the DB context) and deadlock detection and prevention for
> details.

<cough> I've spent the last week deep within the bowels of glibc,
libpthread, and various related libs...  trying to track a bug in
libc-2.1.3-x and below, which seems to be coming from pthread-0.8
and which is not in pthread-0.9 (the one in libc-2.2.x) and which is
only striking under heavy load on an enterprise application, a
serious headache.  I can assure you that threads have their share of
problems... debugging a less than tracable issue is one of the
worst.

>> ...if I should use threads, what would be their purpose? One
>> thread per user? One thread for users, one for game updates, one
>> for mob updates, etc?

> That's a very domain and platform specific set of questions.  It
> really depends on what you are trying to do and your data
> sequencing model.

>   However as a small note in the general case very large numbers
>   of thread are a Bad Idea.  Most systems handle very large
>   numbers of threads poorly if at all.

And java, which encourages large numbers, becomes a problem if it is
used with native (as opposed to green) threads.  And there's a
number of issues with green threads, as well...

--

Nathan F. Yospe -  Programmer, Scientist, Artist, JOAT with a SAK
yospe#kanga.nu   Home: nathanfyospe#mac.com  Work: nyospe at a2i.com


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