[MUD-Dev] Question about multithreaded servers

J C Lawrence claw at kanga.nu
Sun Jan 30 11:22:11 CET 2000


On Fri, 14 Jan 2000 11:11:56 -0600 (CST) 
Fabian Lemke <lemkef at execpc.com> wrote:

> Also one thread for client for rendering what they see based on
> game events, and handling input and output to the sockets.  

Most current OSes do not handle large numbers of threads well,
meaning that if you player base grows, you'll start running into
scaling problems with your OS as your thread count rises
proportionally and your OS starts gagging.

> The problem is that the Area threads will be responsible for
> telling the objects to process scripts, and I'll be needing
> commands to get access to objects that may be in other area
> threads - usually not a problem if locking is all proper - but I'm
> worried about deadlocks because I want objects locked during the
> whole script so nothing can be changed on me.  Since object
> scripts can get out-of-area objects to play with, they have to be
> locked for the rest of the script.  If two objects (not in the
> same area) lock themselves to run a script, and then each's script
> attempts to secure the other.....

Is it possible to list the objects, and thus their parent areas that 
a script will need to access prior to the script's execution?

If so, your answer is fairly easy:  Establish a numerical order for
your areas and their component objects.  Lock your objects and areas 
in strict numerical order.  If a lock fails because it is already
held, just wait.  The other script will finish at some point and the 
blocking script can then continue safely.  

The reason for doing things in order is that it prevents there ever
being a deadlock condition where A holds X and is waiting for Y, and
B holds Y and is waiting for X as the ordering process mandates that
both start by locking X and only then progressing to Y.

> Any ideas how this can be solved?  I'm somewhat new to
> multi-threading, but am pretty sure I have a solid grasp on it
> all, but I've little design experience in it.

Essentially you're talking about locking strategies, which hit for
multi-threading, multi-process, cluster, and parallel programming
cases.  I don't know of a decent web site which discusses or coveres
the area well (if you do, please add them to the Library at
Kanga.Nu), but there are various techniques, from the lockless
rollback system i use, to ordered lock handling, to various
applications of graph theory for deadlock detection.  A good OS
desing book should cover -- I've heard good comments on tanenbaum's
books in particular.

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list