[MUD-Dev] Question about multithreaded servers

[Nick Shaffner]

----- Original Message -----
From: Fabian Lemke <lemkef at execpc.com>
>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.

    IMHO, this is the root of your problem (locking objects for the whole
script).  By nature, deadlocks are far more likely to occur when you have
entire objects locked, even when they don't need to be.  In general, you
should strive to hold as few object locks as possible for as short a period
as possible - though even then you will still get the occasional deadlock.

> 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.....
>
>The only solution I can think of is to have a seperate thread for
>executing scripts, but 95% of the time scripts won't need to access
>out-of-area objects.
>
>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.


    Why not switch to an Event based system and have an event queue for each
area thread?  Classically, properly implemented event based systems are very
good at avoiding deadlocks, simply because of their implicit 'one-way'
discipline.  In addition, the thread that owns the object that a given Event
applies to could/would also be the thread that executes the event - thus
removing almost all need of user level object locking.
    So you could, for example, have a master event queue, running on it's
own thread that would sort all incoming events by the areas of the objects
they applied to and send them down to the appropriate 'area' event queue, to
be handled by that particular area's thread whenever it gets around to it.

                                            Nick
--
My views and my companies views are wholly unrelated.
Nick Shaffner
Programmer: Duke Nukem Forever
3D Realms





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