<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd) --> <!--X-From-R13: X Q Znjerapr <pynjNxnatn.ah> --> <!--X-Date: Wed, 22 Dec 1999 23:38:18 -0800 --> <!--X-Message-Id: E1212p7-0008Pb-00@dingo.kanga.nu --> <!--X-Content-Type: text/plain --> <!--X-Reference: Pine.LNX.4.10.9912222145420.11208-100000@localhost.localdomain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw@kanga.nu"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00756.html">Previous</a> | <a href="msg00758.html">Next</a> ] Thread: [ <a href="msg00756.html">Previous</a> | <a href="msg00763.html">Next</a> ] Index: [ <A HREF="author.html#00757">Author</A> | <A HREF="#00757">Date</A> | <A HREF="thread.html#00757">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd) </LI> <LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#kanga,nu">claw#kanga,nu</A>></LI> <LI><em>Date</em>: Wed, 22 Dec 1999 23:38:09 -0800</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On Wed, 22 Dec 1999 21:54:37 -0500 (EST) Rahul Sinha <rsinha#glue,umd.edu> wrote: > On Wed, 22 Dec 1999, J C Lawrence wrote: >> On Wed, 22 Dec 1999 13:54:23 -0800 Justin Rogers >> <justin#mlstoday,com> wrote: > keep in mind, multiple threads ought not seperate themselves on > seperate cpus due to cache coherency issues... Careful there. Cache coherency is important, yes, but depending on the volatility of your working set flushing your local caches may not be a significant factor in your general performance. Given a reasonably large and active world in fact, this is almost guaranteed. > the only reason to have threads is to eliminate wait for blocking > operations. Not so fast. That is one reason. One reason which I use is so that different operations may run simultaneously at different process priorities. Another reason is to allow more fine grained process scaling on MP boxen. Yet another reason is to help give a facility to present a seemingly fine cooperative grained parallel process model without actually having to implement it or its complex lock semantics. A yet further reason is to gain the simplicity of inherently supporting the same data and process model for local threaded operations as I do for distributed processing operations. > If you have one thread-per-zone, each thread can iterate across > the actions provided by the users, and any blocking that needs be > done (eg database access hits, which are fast, but if you want > your ticks to be under a second, should be considered blocking > operations) does not stop the entire program, the cpu can go work > on another zone. Ahem. Consider the following, taken from a rather old post describing my approach and minorly edited: The server itself knows nothing about the game it is representing. It has no parser, game knowedge, or anything else application specific. All it does is represent a database and provide a scripting language. The database consists of records. Each record defines an object in the MUD world. An object may have attributes, methods, verbs defined on it, an inheritance structure relating its content to other objects. The server is entirely event driven. The definition of "event" below is not the typical systems definition of "event", but rather is used to reference an atomic processing action that occurs within the game-world's purview. It is an "event" in the sense that it is a "happening", or an instance of a state change. Every event executes asynchronously in its own thread using a lockless data model. I don't guarantee order of execution of two unrelated events. The server core consists of the following base units: -- DB -- Dispatchor -- Executor -- Connector The Dispatchor consists of two threads which own and operate the Event List. The Event List contains an entry for every event which has been logged with the system but not processed yet. One thread in the dispatchor handles placement of new entries onto the Event List. The other thread processes the list looking for "ripe" events (ie ones ready to be executed). Ripe events are sent to the Executor where they are placed in an Event Queue. The Event Queue is a priority queue with events ordered by their own execution priority. The Executor manages the Event Pool, a local pool of threads (the number dynamically grows and shrinks at runtime depending on load) which are used to execute the events pulled off the Event Queue. Threads in the Event Pool are re-used to execute ripe events. Events are pulled off the Event Queue in priority order and handed to the first available thread in the Event Pool. Events that fail to commit are rescheduled with the Executor at a different priority and re-enter the priority queue and scheduling as appropriate. Event's have no effect upon the DB or state until and unless they commit. (see C&C and the lockless model in general) Compleated events can log futher/later events back to the Dispatchor for subsequent animation. This is how mobiles are animated for instance. User IO arrives thru the Connector. The connector is essentially a pool of threads which asynchronously manage the general pool of outside connections. A seperate monitor is responsible for keeping the IO network tree happy. User commands arrive at the Connector and are immediately sent to the Dispatchor as Execute-In-Zero-Time (ie no delay) events. The event logged is actually to parse the command as entered. The dispatchor then routes the event to the Executor, it runs the event and the resultant parse creates a new event which is logged with the Dispatchor to actually execute the intended action. You can read about the lockless DB model in the list archvies or the list FAQ (recently posted). > data coherency important, many threads accessing one datapoint > bad. Amusingly for the general case the C&C model explicitly loses this by making most data event-local. Where you get nasty cache contention is for actively referenced objects in the DB copy cache that don't actually get modified by anyone -- but I don't seem to run into that case too too much, especially given the fact that I'm only running on 2-CPU boxes. -- J C Lawrence Home: claw#kanga,nu ----------(*) Other: coder#kanga,nu --=| A man is as sane as he is dangerous to his environment |=-- _______________________________________________ MUD-Dev maillist - MUD-Dev#kanga,nu <A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A> </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00763" HREF="msg00763.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong> <ul compact><li><em>From:</em> Rahul Sinha <rsinha@glue.umd.edu></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00750" HREF="msg00750.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></STRONG> <UL><LI><EM>From:</EM> Rahul Sinha <rsinha@glue.umd.edu></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00756.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00758.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00756.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00763.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00757"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00757"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00732" HREF="msg00732.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong>, Justin Rogers <a href="mailto:justin@mlstoday.com">justin@mlstoday.com</a>, Wed 22 Dec 1999, 21:58 GMT <UL> <LI><strong><A NAME="00746" HREF="msg00746.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong>, J C Lawrence <a href="mailto:claw@cp.net">claw@cp.net</a>, Thu 23 Dec 1999, 01:41 GMT <UL> <LI><strong><A NAME="00750" HREF="msg00750.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong>, Rahul Sinha <a href="mailto:rsinha@glue.umd.edu">rsinha@glue.umd.edu</a>, Thu 23 Dec 1999, 05:36 GMT <UL> <LI><strong><A NAME="00756" HREF="msg00756.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong>, Christopher Kohnert <a href="mailto:cjkohner@brain.uccs.edu">cjkohner@brain.uccs.edu</a>, Thu 23 Dec 1999, 07:34 GMT </LI> <LI><strong><A NAME="00757" HREF="msg00757.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong>, J C Lawrence <a href="mailto:claw@kanga.nu">claw@kanga.nu</a>, Thu 23 Dec 1999, 07:38 GMT <UL> <LI><strong><A NAME="00763" HREF="msg00763.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong>, Rahul Sinha <a href="mailto:rsinha@glue.umd.edu">rsinha@glue.umd.edu</a>, Thu 23 Dec 1999, 17:00 GMT <UL> <LI><strong><A NAME="00772" HREF="msg00772.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></strong>, J C Lawrence <a href="mailto:claw@kanga.nu">claw@kanga.nu</a>, Thu 23 Dec 1999, 17:48 GMT </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="00764" HREF="msg00764.html">[MUD-Dev] Two threads forced to one CPU? (was: Collecting ideas for a MUD server...)</A></strong>, Wesley W. Terpstra <a href="mailto:terpstra@iota.dhs.org">terpstra@iota.dhs.org</a>, Thu 23 Dec 1999, 17:00 GMT <UL> <LI><strong><A NAME="00771" HREF="msg00771.html">Re: [MUD-Dev] Two threads forced to one CPU? (was: Collecting ideas for a MUD server...)</A></strong>, J C Lawrence <a href="mailto:claw@kanga.nu">claw@kanga.nu</a>, Thu 23 Dec 1999, 17:31 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> </UL> </LI> </ul> </ul> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>