23 Sep, 2008, Rojan QDel wrote in the 1st comment:
Votes: 0
Has anyone experimented with making a SMAUG/SWR mud multi-threaded? If so, how difficult was it and what were the results/speed increases like?
23 Sep, 2008, David Haley wrote in the 2nd comment:
Votes: 0
Yes, I only did brief experiments so it wasn't too bad, but the benefits were not really enough to make it worth it, except for things like DNS lookups. I wouldn't go forward with multi-threaded without having solid numbers to argue for it, like showing where things actually block for a long time. Multi-threading won't really help unless you have long blocking operations somewhere; there aren't a lot of parallel operations in MUDs.
23 Sep, 2008, quixadhal wrote in the 3rd comment:
Votes: 0
I fully agree with David here.

Multi-threading brings a whole new set of complications to your coding style, because you can no longer guarentee the order in which things happen, unless you make extensive (!) use of semaphores (or other mechanics) to ensure certain parts of the code will wait for others to complete, and that no two bits can try to modify the same data at the same time.

In practice, the complexity of writing and maintaining threads usually outweights the gains, unless your problem is easily dividable into distinct work units. Almost everything in a MUD tends to need to look at everything else, so I believe you'd spend a lot of time waiting in semaphore locks, rather than doing more than one thing at a time.
23 Sep, 2008, elanthis wrote in the 4th comment:
Votes: 0
For things like MMOM/MUD game servers, multi-threaded is not really the way to go. You want to aim for a multi-process model.

As already mentioned, dealing with synchronization and data concurrency issues is pure hell. In something like a game, you have a ton of different ways objects are generally accessed. Unless you go for a pure event-driven model (which don't really work in practice – you end up needing some kind of polling here and there at least) you're never going to get object update logic to work without big global locks.

A multi-process model lets you cleanly separate parts of your game. For example, each area/zone might gets its own process. Objects and mobs are not able to talk to or otherwise interact with objects and mobs in other zones. Players would be transfered between the zone processes as they move around, usually using a frontend process that would handle the actual client/server TELNET communication and pass messages to and from the areas.

You can of course due that with threads, too – it's more about the design than actually using thread/processes.

That said… your MUD is going to have like 100 players, tops. Maybe an astronomical 250 if you make it into the top 10 of all active MUDs. Welcome to 2008. You are not in any need of ever worrying about needing threading, unless your code is doing something monumentally stupid.
05 Oct, 2008, exeter wrote in the 5th comment:
Votes: 0
elanthis said:
Welcome to 2008. You are not in any need of ever worrying about needing threading, unless your code is doing something monumentally stupid.


I prefer to use a cooperative threading model. That way, you can express code in the natural way while simultaneously not having to worry about locking and stuff. For, as you said, 100-250 players, this is plenty good enough. If you needed to scale to thousands of players (for, say, an MMO), you can still do this, but you'll have to go with a multiprocess/sharded type archictecture.
05 Oct, 2008, Chris Bailey wrote in the 6th comment:
Votes: 0
exeter said:
If you needed to scale to thousands of players (for, say, an MMO), you can still do this, but you'll have to go with a multiprocess/sharded type archictecture.

This isn't at all relevant to the thread but I just have to say that I keep seeing this acronym MMO used like "Blahblah is an MMO" and I'm confused about how you can refer to something using an adverb and two adjectives. If I said that Daryl is a "mostly fat excited" it wouldn't make any sense, yeah?
05 Oct, 2008, exeter wrote in the 7th comment:
Votes: 0
Chris Bailey said:
This isn't at all relevant to the thread but I just have to say that I keep seeing this acronym MMO used like "Blahblah is an MMO" and I'm confused about how you can refer to something using an adverb and two adjectives. If I said that Daryl is a "mostly fat excited" it wouldn't make any sense, yeah?


It's an anaphoric construction where the "G" is assumed implicitly, because the thing you're talking about is known to be a "Game" from context.
06 Oct, 2008, David Haley wrote in the 8th comment:
Votes: 0
I don't think you mean anaphora, but I'd grant your argument about the 'RPG' being assumed…
0.0/8