Computer Science Canada Multi-threaded design |
| Author: | Zeroth [ Fri Jan 09, 2009 9:58 am ] |
| Post subject: | Multi-threaded design |
So I've got a rather high level question to ask/discuss here. In what spare time I have, I'm currently looking at writing a MUD, for fun. One idea I've been considering is a multi-threaded design, with each player in their own separate thread. This has certain benefits, in that if one player screws up badly, it doesn't crash the entire mud. But it also has a certain trade-off, in that this adds complexity to the design, and a whole new class of difficult problems. I know there is a bunch of different kinds of servers, which I remember very vaguely from a book on Twisted, stuff like the Reactor server model, Concurrent threaded server model. What I'm just wondering is, what would be the best way, design-pattern-wise, to make this work? It will potentially have to work for hundreds of players. What I'm thinking about is a small pool of threadlets, ready and waiting for players and connections to be attached. Someone connects, they get one of these threadlets, which then handles the login, etc. The simplest way to handle multiple access to data is to create a couple of shared queue, with each threadlet getting its own section in the queue. This way data is not overwritten. I've done this before, where I built three shared queues, had multiple producer threads, and multiple consumer threads. After every read/write operation, the queues are rotated, with read going to fallow, fallow to write, write to read. I was able to get up to about 8000 threads on a decent machine on python working mostly concurrently in one second, with no data corruption, or slowdown in processing data(Although you have to make sure that the number of threads is even for both producers and consumers, so that you can guarantee the thread will get new info). My worry is that this is unnecessary overhead, if the select model(Reactor model) is good enough. However, the benefits of a multi-threaded design are nice, and enable a good separation of players from the main core. I could always use an amalgam of this design, where the select polling takes place in a separate thread. |
|
| Author: | btiffin [ Fri Jan 09, 2009 11:29 am ] |
| Post subject: | RE:Multi-threaded design |
Take a look at this paper; might give you some hints. http://www.cs.indiana.edu/classes/b534-plal/ClassNotes/thread-design-patterns4.pdf It's a short two page overview of some common techniques. Then google some of the 3 threading methods mentioned, see it they float your boat. The Version Stamp technique may save you from all your consistenty worries and let you pick whatever model seems best, and allow for easier change to the core when deemed necessary. Cheers |
|