From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Newsgroups: rec.games.mud.lp
Subject: Re: DISTRIBUTED MUDDING
Date: 16 Dec 1992 14:35:31 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: tartarus.uwa.edu.au
X-Newsreader: Tin 1.1 PL5

Mark Johnston (markkj@mullian.ee.mu.OZ.AU) wrote:
: 
: 	I was interested to read all of these articles talking about having
: actual rooms distributed across the different mud servers, as I have started
: working on a multi-processing mud (by this I mean that the mud is run on a
: machine with >1 processor) with a friend.  We decided to start from scratch
: with this, as modifying the LP code could be a nightmare...  The design
: is to have a separate compiler, which produces some "m-code" (just some
: plain old byte code), and this code is executed on one of several virtual
: machines (VM's for short).
This is nice and normal. The sane way to go. Just for intrest sake,
how did you handleing multi-threading at the C level? Did you
multi-thread the C? Or single thread the C, and indulge in all sorts
of horrible code to make it never block? (My way. )

: The threads of execution can move between VMs,
: to make sure that the maximum throughput is obtained.

This is easy enough to be doing, but I am still not sure you want to
do it. Given the thru-put in thread execution, and current network
speeds, I can't see an advantage in the usual case. Something that
should be support "just in case" tho by all means.

: One of the other
: reasons we decided to write a mud was to add a tile-based map system to the
: game.  Objects are to have a number representing a 'sprite' number, and
: all objects that can contain other objects have a 'map'.  The map represents
: the layout of a room, and on top of this, the object sprites are
: drawn.

It would be nice not to have the driver need to know about this. This
is certainly something I thought in the direction of for my driver,
but I can't see the driver ever needs to know about it???

: This
: requires that all move_object() calls send updates to all interactive objects
: that are in/near/containing the moved object.  This in itself would slow down
: the rate at which the threads of execution are executed.

Not nessecerily (sp!?!). What should be happening , is that when an
object moves out of the room, it notifies the room, nothing else. Then
the room worries about telling any objects that need to know. This
moves the burden of work to a nice pseudo-central object. Slightly a
semantic difference, except that the room would process this
concurrently with the object moveing out, and , in any net-work
sensitive implementation, would 'bundle' updates.

:To coordinate the variable-locking on a system like this is not easy to do,
:as two processes writing into a shared memory segment can do this at the same 
:time.  Using shared semaphores is a way of getting around this problem, but as
:one could imagine- it gets _very_ messy.  The solution that we've come up with
:is using a single driver to do all of the task-allocation(Tasks are threads of
: execution within the objects, but they are not bound to the object that they
: started in...) over all of the virtual machines that interpret the byte code.

Hmm. I moved this into the language. This is fairly mostly just
semantics, but what I do is...
	{
		a block of code that needs no mutual exclusions.
	}
	{{
		a block of code that is mutually exclusive on this
		object. Only one thread can be executing this code
		with this object as 'self'.
	}}
	{{{
		a block of code that is mutually exclusive across a
		class. Only one thread can ever be running this code.
		needed, as I have variables global to a class.
	}}}
These take care of most cases.
What they DON'T take care of. 
	Deadlock. This is a major ARGH!!!! I still have't sorted out
what to do here. A thread can never exclude itself, which solves a
fair amount of pain, but it is still possible.
	Objects like this: two functions read(), and write(). Any
number of objects can be calling read(), unless write() is called,
then no objects can be reading. Only one object can be running
write(). The current scheme doesn't allow for this. I did look at a
system that seemed to allow it, but it wasn't very pretty. Ideas
anyone?? 
	 
:     Expanding this idea to a mud that works across different machines, rather
: that just processes on one machine would have some benefits and a number of
: disadvantages.  The disadvantages inculde the lack of a distributed 
: shared-memory system (the m-code is stored in a shared memory arena, so that
:the VMs don't have to send requests to the driver to get hold of the code that
: they're supposed to be executing...) which would mean that the m-code would
: either have to be passed to the different drivers by NFS or through sockets.
: (I know how much the systems people at most universities would appreciate
: setting up NFS links to places halfway around the world... :-)

This is simplified is you try and make EVERYTHING an object
(includeing code!). This then "simplifies" to sending objects around.
No problems.... ;)

:     A distributed version of our mud would work well for local groups of
: machines, but for international groups... it could be a bit slow.

Distributed IMHO means makeing independant parts of the mud, network
independant. Ideally the link speed to other hosts should only rarely
manifest itself.
 
:         Mark. (aka Farlinnin)
Michael