[MUD-Dev] Multithreading: AI, Sockets, Brains, Bodies, and Storage

[Caliban Tiresias Darklock]

From: "Brian Lindahl" <lindahlb at hotmail.com>

> Multithreading: AI, Sockets, Brains, Bodies, and Storage

This may be the best post I have ever seen on MUD-Dev. A lot of
people have been asking for this, and I think it's fantastic that
someone has taken the risk of posting a more or less complete design
blueprint.

>     - SpawnTiedThread creates a new tied thread

What is the functional difference between a thread and a tied thread?

>   Since AI only reads game data, Storage can be done concurrently
>   (assuming input/output tokens are not serialized as stated
>   above).

Doesn't this still create a race condition unless you use a
transaction system to guarantee consistency? I'm having trouble
thinking of a compelling example (I can think of many stupid ones),
but if the AI needs two pieces of data that are being changed at the
time, couldn't it read one value on either side of the update and
become confused?

I've been thinking about a design that works a little differently,
specifically by treating all data as events. When a player enters
input, a "read socket" event goes into the event queue just like
everything else.  When the game gets to that event, it reads the
socket and tokenises the data, then sends the tokenised command as
an event; this produces other events which will generate the output,
which is placed into the queue as further events. This allows
multiple threads to execute concurrently on the events, and since
everything is processing the same variety of data, all the threads
are the same. Why haven't you chosen that sort of solution?


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev