[MUD-Dev] request for comments

[Miroslav Silovic]

Mike Sellers <mike at online-alchemy.com> writes:

> At 05:03 PM 1/6/98 PST8PDT, JC Lawrence wrote:
> >To describe my system loosely, and briefly:
> >
> >  The server is heavily multi-threaded (I think the idle-state is over
> >50 threads currently).
> >
> >  All events are processed aynchoinously and in parallel.  
> >
> >  The server is lockless.
> >
> >  I don't guarantee order of execution of two unrelated events.
> 
> So... without recapitulating the flamage on this that occurs regularly in
> r.g.m.*, how do you handle things like the "Dragon's Dinner" scenario,
> where the player thinks she has closed the door behind her, but then is
> surprised when she is fried by the dragon anyway (who, in this race
> condition, saw the door as "open" and went through)?  In a truly lockless
> system, aren't race conditions inevitable?  

This is likely to show up in the FAQ, isn't it? ;) Also, it's in the
archives of this mailing list, where the problem has been beaten to
death, with several good solutions.

The idea is described in detail in any good database management
textbook.  Instead of locking (and having to worry about deadlock
prevention), you instead use transactions and delay effect of every
thread until the commit time. If you can't commit, you rollback the
entire thread. The net result is that threads /seem/ to execute in
sequence - because when two thread interfere with each other, only one
will be able to commit.

I designed specification (well, pretty rough /beta/ specification) for
the similar system that could be implemented for Cold, and I discussed
it on this list as well. Of course, there are no promises to stick
with the original design, because there /are/ certain things with
JCL's idea that I like. Don't hold your breath, though, it's waaaay
down TODO list (after implementing different, thread-safe memory
management and hacking VM for threading).

--
I refuse to use .sig