Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 11-15-2012, 07:43 PM   #1
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Event-based with threads instead of game loop

This is my first post, but I've been following you for a while. I'd like to start a discussion about the thing put in the title (saying goodbye to game loops), as a starter, and possibly get some feedback about my own project.

Ok, so here's the thing. As many before me, I decided (11 months ago) to start making my ideas concrete. The language I best knew was Java, and still is, so I started looking for Java codebases..but after a few source code browsing on sourceforge, I understood I could do it myself, maybe better (the Java codebases I've found are all seemingly dead anyway).

I decided to challenge myself on a particular design aspect: not using a game loop at all. On a linux machine, with Java 7 and a quad-core 64 bit, tens of thousands of (small) threads can be executed at once without the system being slowed down at all. I've searched around for statistics on that and it seems confirmed.

I've been using blocking IO on sockets, since for each player there is a dedicated thread and the blocking IO make the thread sleep most of the time, saving computation. Various "worker threads" do background stuff, like waiting for commands to be executed, waiting for new users so as to create a dedicate thread on the fly, doing timed events etc.

I guess, with the number of users of modern MUDs, I'll be having at maximum a few tens of threads, maybe if I'm overly lucky on the order of 100. Still, acceptable performance wise since, at a particular time t, most of the threads should be waiting/sleeping.

As far as I've seen this is a new approach to mud coding. Am I right? Or have I just been too quick on my web search one year ago?

There is a particular thing I still have somewhat in common with game loops style approaches. I have a thread, ActionExecutor, where each Action (can be a player Command, or a MobAction, or a RoomEvent) has to pass on to be executed. This guarantees a sequence of actions.

If player A issue a command before player B, it won't happen that the command B is executed before, as it could in a totally decentralized system. At the beginning I was going to make it decentralized, but this sequence problem and the need of carefully design the concurrency to avoid deadlocks just drove me to this other solution.

So far I have implemented the few basic mechanics that allows it to be called a MUD-like thing. Players, mobs, objects, rooms, take-wear-open-lock and the opposite commands. It is like a chat with object interaction and world navigation.

I am just not sure if this approach is actually feasible. When more commands will be implemented, I'll pick up some friends and random people to do a mass connection issuing commands at maximum speed, to see if they are able to lag the server.

I'll surely need to do deep optimisation in the future, using a profiler, but in general terms what do you think? Is it possible with today's hardware to have a event-driven, highly threaded mud? It seems like in the next few years we're going to have cpus with a lot more cores. Intel is already selling 6-cores cpus, but what about a cluster of 100 raspberry pie? It'd be something like one for each player (or even more). The MUD would be extremely reactive in this way I guess.

Well, that's a long first post I look forward to your opionions and thoughts about this.
koteko is offline   Reply With Quote
Old 11-15-2012, 10:50 PM   #2
Ide
Senior Member
 
Join Date: Feb 2006
Location: Seattle
Posts: 361
Ide will become famous soon enoughIde will become famous soon enough
Re: Event-based with threads instead of game loop

Welcome to TMS koteko, good to have you here.

I've seen some muds use this approach. I think it wasn't used much in the past for performance reasons as you imply, but if your profiling shows acceptable resource use I don't see why you couldn't use it now.

For testing I'd advise you to write or find some kind of framework that'll throw a lot of connections and commands at the server so you can profile properly.

I've heard people say that a design like this makes the code a little more straightforward to write and understand, which can't hurt.
Ide is offline   Reply With Quote
Old 11-15-2012, 10:55 PM   #3
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: Event-based with threads instead of game loop

All right, I'll bite.

Yes, it is possible. You do not want to do this.

There was an attempt, that I heard about through hearsay, to do this very thing. It ended miserably, maybe someone knows what this was. I saw it in a thread, around one of these sites...anyhow.

Coffeemud is done in java. I don't know if it's "dead", but it is more featureful than a lot of options. Do remember that whether or not a codebase is dead isn't the point: codebases are starting points, not finished games, and a quality codebase is a quality starting point even if it isn't actively developed (that's your job, once you start your mud, anyway).

So, threads. You can't do a lot of things that seem like a good idea: you can't have a thread per object, you can't have a thread per mob, you can't do any of this stuff. You're going to have all sorts of problems, especially if you want to give your builders any real power with a scripting language: now builders have to learn about locks and mutexes, or you've got a thread that's always running scripts for your mobs, and that's going to partially defeat the purpose. There's a reason game loop with non-blocking IO is popular (see merc, or just about any codebase out there): it can be debugged without pulling your hair out, you can find coders that can understand it, you can find coders that can, in short, actually manage to code on your project. If you are a really good programmer with experience in this area, you will be able to pull it off, but no one else, not the typical adopters of your codebase anyway, will be able to work with it. There is a reason that people don't use threads heavily in everyday programming. If you do this only for your game, you might be able to get away with it, but you're going to have to find a way to build an abstraction layer that makes building single-threaded, somehow, and you can't be telling builders, who in a lot of cases don't really know programming, "O, that doesn't work, it creates a race condition, write it another way". Congradulations, you've got a technologically cool project that no one else can understand, but hey, that's ok, it uses threads.

You're not gaining anything, not really: it's going to be slower than the game loop approach, at least for an average mud, whether it lags the machine or not. 99% of the time, even if you're doing some pretty serious string processing, you're not going to lag the mud noticeably; I don't remember where I got this statistic, but for the average person, the mud doesn't lag until after 100ms of unresponsiveness, that is, no one notices. So cut that in half, and you've got 50ms before you have to get back around to a player again--in computing terms, for a mud, that's rather a lot of time nowadays. Also, my understanding is this: you can have as many threads as cores on your machine before you start losing performance: if your codebase will never run on another machine, under another java runtime, you can tune it. Otherwise, it needs to self-tune.

I think, if you're going to use threads, some sort of "worker" threads aren't a bad idea. I'd say, for example, that moving the asynchronous loop to pull input from players to a thread isn't a bad idea, but I'd not give each player his or her own thread. In addition, I'd not process the commands there, I'd add them to a commands-to-process list and process them in the game loop. I'd say, if you're making a long query to a database, maybe thread with callback. But threads, in mud programming, are not the best way, not by a long-shot.

If you are dead set on this, you need to probably look at something like akka. It has actors, which are like threads but not really: an actor is like a method call, and if more than one can be executed at once, akka will attempt to do so. For real-world use, I'd avoid even that and just get some sort of implementation of futures; you're not using scala, so the code would be a bit ugly, but this is available in java, and does something that I think would be worth the cost of added complexity.

Finally, do keep in mind that this will come back to bite you one day. You'll be programming happily along, and all of a sudden the mud will just freeze, and you'll have to find the resource two of your important threads want to use at the same time. Off the top of my head, a few things that make this complex: caching data to disk (two threads want access to an object not currently loaded, and they want it at the same time. They both decide to load it. What happens?), two commands that want to delay their output getting interleaved on my terminal because you used threads (spells and skills do this, at least), the fact that combat is typically done in rounds (good luck determining which order people get hit in, if everyone might be running on a different thread, and yes this does matter: whether or not I hit first or you hit first will make the difference in some strategies, and will add an unintended random variable to combat)...

If you have a lot of prior experience with threads, go for it, I guess, but no one else will be grabbing your project in a hurry.

It is argueable, if you want to look for a happy middle ground, that continuations would be useful. Java does not support this, and it would be hackish to get it to do so, and your code would be ugly, but if you're not adverse to porting to scala or something that does, it does exist. The gain may not be worth the trouble, not at first, but it would allow you to write commands that can give other commands the ability to execute at the same time, and someone could maintain the parts that don't need you to know about it, i.e.:
pause() //give the mud a chance to do stuff.
And when it gets back to you and resumes your continuation, you're in the same state (kind of) than when you paused. But this also has issues, and in a multi-player environment is probably going to have more problems than it's worth, and I don't understand them enough that I can list those problems for you without a lot of reading that I'm not going to do right now.

For the record, I did think threads were the future for muds once. Save yourself the trouble that's coming your way and just use the game loop: there's a reason people haven't moved away from it, there really is.

edit:
I missed the part about An executor and this makes this less bad, but only slightly. You're still going to have all sorts of problems, once you move to mob scripting and combat, and you're only going to implement the command interface once anyway. Most people, on the current codebases, never have to touch the i/o portion: just add your command and function pointer to a table in c++, or in coffeemud/etc just add it to a directory and java reflection can find it. Do be aware that most muds, disregarding lpc and the 4 or 5 big ones, use under 10 mb ram and under 1% cpu (this varies depending on cpu, obviously). If you really want something that doesn't use a game loop, there are other options, i.e. the abovementioned actors and futures, that may work better, depending (actors are not deterministic, if I recall correctly, so that might be the issue there). There are codebases that have implemented events on top of a game loop, and I do like this system: "do this in 5 seconds" is fine, so long as the underlying implementation is reasonable. If you insist on using threads, and this is intended for the general mudding community to use, the fact that it uses threads needs to be hidden very, very well: i'd say 99% of the time, as someone working with the codebase, I need to not see the word thread or think the word thread. Actors, by the way, scale really well: i've heard everything from 50000 to millions, and suspect the truth is somewhere inbetween (and depends on machine).

Last edited by camlorn : 11-15-2012 at 11:18 PM.
camlorn is offline   Reply With Quote
Old 11-16-2012, 03:47 AM   #4
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: Event-based with threads instead of game loop

No, it's been suggested many times before, try googling for "the dragon's dinner problem". The common opinion is that multithreading in muds isn't worth the trouble, except for specific tasks (many muds do use a separate thread for DNS lookups for example).

The event system is more viable though, and has been used successfully in a number of muds.
KaVir is offline   Reply With Quote
Old 11-16-2012, 04:04 AM   #5
Ide
Senior Member
 
Join Date: Feb 2006
Location: Seattle
Posts: 361
Ide will become famous soon enoughIde will become famous soon enough
Re: Event-based with threads instead of game loop

In his case multithreading is no trouble at all (except for the possibility of running out of resources) since he's avoiding race conditions and locking by pushing events onto queues. I think his approach will be less trouble than a typical mud game loop.
Ide is offline   Reply With Quote
Old 11-16-2012, 04:33 AM   #6
Viriato
New Member
 
Join Date: Jul 2007
Location: Lisbon, Portugal
Home MUD: Iberia MUD
Posts: 22
Viriato is on a distinguished road
Re: Event-based with threads instead of game loop

Good evening.
Iberia MUD is Java and multithreaded. One thread per client, one thread per core system. It is possible and not that consuming in a fair homemade server (just tested with few players). It is very interesting the fact that if something breaks, just that thread will be stuck and the rest will work as supposed (for instance, when combat breaks noone can fight, but the rest is up and works as supposed - army combat, all sorts of communicationm, etc). I get some troubles setting concurrency at times, but that's because development is slow and I forget some details :P

There is an important drawback: with one thread per client, if for instance two players "do 20 north", they wont arrive at same time (that's never like that, but the point is that there is no pooling of actions). Or I force a general pooling (which makes half the purpose of threads pointless), or in this special case I've put a delay in movement for everyone (still differs, but much less, and it's fairer).

Ah, items and objects don't have individually allocated threads. To give them "life", though, I made one thread for all moving NPC (it just deals with a big list and "distribute" orders to NPC when the time arrives) and one thread for temporary phrases. So, main architecture like that (weather has it's own thread, season of year the same, etc, etc).
Viriato is offline   Reply With Quote
Old 11-16-2012, 07:12 AM   #7
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: Event-based with threads instead of game loop

Wow, thank you guys. That's a awesome lot of answers. I see that I've definitely been too fast in my search of codebases, I'll have a look at CoffeeMUD but..I fear my own self-challenge won't allow me to throw my code in the rubbish.

Let's go in order, anyway:

@Ide: thank you for the suggestion, I'll surely use a framework to stress-test my little MUD or I might write a bruteforce user-faking class for the purpose. I'll just have to add a few milliseconds to each socket transaction to fake the internet delays.

@camlorn: I'm processing the tons of suggestions you've given me I'll look into akka too. But I guess some of your remarks would only stand true in a totally asynchronous system. I don't totally understand that "edit" part though. I do use reflection to get the commands, and I don't have to touch the IO: the threads dedicated to the player pre-process the strings, get the correct Command class instantiating it and than they put it in a global blocking queue.

The ActionExecutor blocks on this "pendingCommands" queue and when something comes up, it executes it. So far, with no optimisation, each command takes less than 1ms to execute (I should start looking at nanoseconds to improve things). So unless in the same exact moment (the very same millisecond) are issued 100 commands, the user would see the effect of his/her command without lag (I'm using the 100ms rule of thumb here, but you get the idea).

For the rest, there is no trace in the commands' code of threads things, since the single command is going to be executed sequentially. Also, I don't think the building layer would need in any way a mention of concurrency-related stuff, considering how mob AIs or Room events are going to be issued and built inside separate threads, but executed into the same action executor. But I haven't implemented yet a building layer, so far it's pretty much all hard-coded (MobAIs are classes, and I use reflection at bootstrap to get the corrent AI-class for a particular mob just loaded).

I don't see a problem even in combat, for example. I'm going to implement a first version of this shortly, and my first thought is about timed tasks and status variables. For example, if player A attacks player B, and the fight begins, they both will have a status "IS_FIGHTING". According to their skills and other things, a first TimedTask will be issued from the attacker, let's say in 1.5 seconds, to do the first hit, and at the same time another TimedTask will be issued from player B, the defender, let's say in 2 seconds, to do his first hit. They will run as timed, very short-lived threads, just doing this:

1. check if the player is still fighting
2a. if yes set up a hit (this is a Command that will go into the ActionExecutor)
2b. if not, terminate

The command that makes the hit will do what it has to, but in addiion it will also have to either stop the fight for some reason, by changing the status of both players to "IS_NOT_FIGHTING" or something, or to issue another TimedTask for the next hit. In this way I can control, for example, also shorter distance hits (the command Hit at time t will issue a TimedTask in 0.5 seconds instead of 1.5 seconds).

At this point of development I don't see any drawbacks, but I'm not sure.

Just to mention it, there isn't overhead in creating this little timedtask (at most, at a particular time there can be as much TimedTasks as logged players+active mobs) because I am using ExecutorServices with thread pool caching. I could even reduce further the overhead by using the Command itself as a TimedTask. Actually now that I say it, it seems more reasonable and quicker to do.

@KaVir: just searched for the thing, and I might have read it one year ago because it gave me the same willingness to NOT go for a totally asynchronous system, but using a global queue for pending commands. Thank you for reminding me of it

@Viriato: Nice to hear this from you! So you have actually been more brave than me: you went for a totally asynchronous thing and make it work. For the rest, I am following your same approach: a MobAI class (actually two of them, one for all the mobs and the other for active mobs, in this way I can have immediate reaction from aggressive mobs, for example, when a player enters the room, and I still "move" also the others that are far away from any player), and I plan to use a dedicate threads for many other things like the weather.
koteko is offline   Reply With Quote
Old 11-16-2012, 02:33 PM   #8
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: Event-based with threads instead of game loop

Going to try to clarify a bit. The edited part could probably be clearer, but for some reason firefox crashed twice before I could post it, I had to move to internet explorer, and by that point I was too frustrated.

Anyhow, it's like this. I, the mud newbie, want to start a mud, yay me, so I go download your codebase (this happens a lot, look around the forums). I don't know much about programming, and I want to add a new whatever, command, spell, doesn't much matter. So I go look at how to do it and the first thing I see is this thing called a thread, which I've never heard of. So I go try to add a command, but I can't debug, and I don't know what I'm doing, and I'll probably end up throwing out your codebase. My point was that an executor thread makes this more feasible, but only if the fact that things are running on an executor thread is hidden. If you are going to be the only programmer, and don't want to try for more general adoption, it's not such a big deal. Writing mob scripts could or couldn't become interesting, I really don't know.

Akka is something I don't fully understand; let me start off by admitting that. I understand what it does, just not how to use it. But here's a quick explanation of the idea behind an actor as I understand it, and why it may (or may not) work.

On a cpu, I have 4 cores. This means that for "true" multitasking--tasks running literally at the same time and without time sharing by the OS--I can have 4 threads. I can have more than that, if some or most of my threads are sleeping, but I can't have more running, or two of my threads are going to share a core. This means that my code needs to figure out how many cores are available and determine the best running case. In a mud, given that it really doesn't use that much, you can probably just deal with the time loss.

Actors say, do away with everything is a thread. Instead, everything is an actor and may receive a message. You can have an actor that takes up an entire thread and sends messages to the others--by my understanding this is a common approach--sending messages like "tick" or whatever. I then write my actors more like state machines (not really, but it helps to think about it like that, in a way). Each message will wake up my actor, cause it to do something. If I want a message back, I can wait for a reply, or more commonly, I can go do something else and check for a reply when I need it later. There are no such things as locks or race conditions: instead, you have an actor that is in charge of a resource, and only that actor can get at that resource, and if I want something from that resource I send a message to that actor and wait for a reply. My actor blocks the thread that it's on until it stops executing, at which time another actor gets put on that thread behind it. The trick here is to make actors that don't block, i.e. wait for 5 seconds before returning.

To implement something like a delay, every time I get the tick message, I decrement a counter; when that counter gets to 0, I do whatever I was delaying to do. In languages like scala with closures and such, it's actually possible to do a lot of neet tricks here: inherit from the generic wait actor, for example, and set a variable to the function I want to call. Scala makes this simple and easy: typically, actor ! message(parameters), but scala isn't exactly trivial to understand, so I'd not switch just for a convenient syntax.

So, how do you make it deterministic. Well, each actor has a mailbox, and akka provides a variety of types: I can have priority mailboxes where every message is prioritized, I can have queue mailboxes, there's a whole bunch of options. So long as all my actors aren't running at once, I can have hundreds of thousands, and the akka system will handle determining which ones need to run on what threads. I just bind my game-controller actor to a thread all its own, and let it send messages like tick and regen or whatever to all the others (you can have actors register that they are interested in a message if you want to make it more efficient, and want to prevent waking up 100000 at a time). I don't know if this is deterministic enough, but in a language like scala at least, it looks almost like method calls, and you can just say that a command can never wait unless it uses the trick you outline somewhere in your documentation.

And, this doesn't much matter, but akka does a lot more. If I code it correctly, i.e. everything is an actor, and if I want to look up something about or change a room I send a message to the actor representing the room instead of having a room class, I can then make it such that my mud runs across multiple computers. Akka handles all the serialization and such, and so long as I'm careful to make everything an actor instead of a class, I get simple inter-computer calls (well, kind of. you do have to deal with some stuff--i.e. one of the computers being turned off). There probably isn't much point, not for a mud, but I do have an idea that it might be useable somehow to make some sort of multi-mud where everyone hosts their own areas, or something. I am nowhere near smart enough to actually design that, though.

To me, actors are what you want here. But, to me, using a simple game loop is more what you want here, and I do have to say that I'm going to stand by that.

Time to go look up the dragon's dinner problem.
camlorn is offline   Reply With Quote
Old 11-16-2012, 06:49 PM   #9
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: Event-based with threads instead of game loop

Thank you very much for the thorough message. This actor system seems worth to be checked out, I'll look into it. It seems like a framework that do, under the hood, something similar to what I do now, but surely in a cleaner and more efficient way. I'd also like to learn Scala (on coursera there was a free course from the creator of Scala, I missed it sadly). Let's see. I'd especially love to make the server a distribute system as you suggest..even though I fear that's too much for my current knowledge, yet I do love learning new things. I still don't understand whether akka is totally asynchronous or it can be made synchronous, but I think that's just my very poor understanding of it.

I should have clarified however that I'm not going to release the source code, so the important things are that: it is enough performant to not have lags, I feel comfortable with it (and I love it, I must say, I find it the cleaner piece of code I've ever written) and it scales well with added complexity, ie the combat system, delayed commands, the magic system (the MUD is actually totally focused on the magic system, maybe I'll talk about it in the near future). Of course, in addition, building should end up being as straightforward as possible (but not simpler than that but I think my system doesn't make it more complicated in any way.

The fact that other people have tried the multithreaded approach is both good and bad. Good because if there are codebases it's doable, bad because if there aren't actually running MUDs it might mean it does not scale well. I guess, unless the akka system conquer my heart while studying it, that I'll let you know how it goes. I'll also look forward Iberia MUD which is even more extreme.

I did, and actually now I'm really curious to know how Viriato solved it in his IberiaMUD. As said however that's not really a problem with my own system: the command Move of the dragon (which contains the check on whether the door is open or not) and the command Close of the player would be executed sequentially according to which one arrives first to the pendingCommand queue, so it's easy here. With a game loop too.

For a fully asynchronous system, a lock on the door object would solve the problem in that particular case, with really little effort and overhead. A remark I've found on the internet is about what happens with crowded rooms, or with fights. You need to put locks pretty much everywhere to avoid race conditions, and this might end up being slower than a game loop.
koteko is offline   Reply With Quote
Old 11-16-2012, 09:39 PM   #10
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: Event-based with threads instead of game loop

Well, akka is synchronous, but not. If you have only one core, and akka decides that the best configuration for your system is to have one thread, all actors will share that thread. It will not appear to be synchronous, if you code the actors correctly; this is why non-blocking actors are important. But, if akka decides that your system can handle more than one thread, then actors will share the number of threads that are available, and it won't always be synchronous. If all method calls are turned into actor messages, and you refactor the code so that you use the reply mechanisms properly, it is possible to either have it be synchronous (with appearence of asynchronous behavior) or truely asynchronous. The akka kernel, unless reconfigured by you, will determine all this automatically. What you would probably do is have one blocking actor that blocks for the duration of your game, and have it send messages to other actors that are non-blocking representing your objects and players, etc. I am butchering akka, here, as it's something I've read a lot about but never really used; akka and scala is typically more research-oriented, though some big companies have adopted it (either facebook or twitter, can't remember which atm), and most of the examples aren't something practical. I doubt, unless you're using scala, that you will "fall in love" with it, but I do maintain that an actor system of some sort will avoid a lot of headaches. If I were coding a mud and decided to abandon the game loop, I'd use actors over threads any day. And, to give it credibility, the people developing scala made their actor system deprecated and are now shipping akka actors with the release candidates for 2.10, with the intent of making it a core part of the language, or something very close to that.

Actors, as a general concept, are a different, more light-weight and argueably less complex, model of multitasking and asynchronous behavior. Thinking of them as threads isn't how it works, not really; doing so will probably lead to difficulties in embracing the concept. The underlying actor library or system will handle the thread part of the equasion for you.

As for learning scala: you can learn enough to use it as the "improved java" in an afternoon. Porting existing java code is easy enough, and they do interop (scala to java--the other way is a bit harder, but very doable, so long as you don't use scala's ability to put symbols in method names).

One nice thing scala offers is this: I saw an example once that actually defined a special // operator on integers that allowed one to do things like val x: fraction = 1//2 (val and var are different, and a bit complicated. it's kind of like a variable). You could then multiply and divide fractions and do anything you cared to with them, include add them to whole numbers and such, and they were represented internally as fractions, and they looked identical to using an int or a float, and you couldn't tell the difference. There's cool stuff in scala, but there's gotchas, too, and I'd have to say don't go learn it if you've got something half-coded in java.
camlorn is offline   Reply With Quote
Old 11-17-2012, 07:35 AM   #11
Viriato
New Member
 
Join Date: Jul 2007
Location: Lisbon, Portugal
Home MUD: Iberia MUD
Posts: 22
Viriato is on a distinguished road
Re: Event-based with threads instead of game loop

In Java there are static and synchronized methods For instance, about entering and leaving rooms, the core method is static and synchronized meaning that noone really moves at the same time. Also, some actions are done by iterating collections - an operation that can also be synchronized.

This may or may not cover all troubling situations, but how I idealized each of my systems there is no need for extra cautions (that I can think of).

Example: if someone says something in a room, it iterates the synchronized list of all players and NPC there. If in middle of that command one wants to leave the room, it will try to make a parallel remove in such list. As both operations are inside of a "synchronized" block in both threads, only when the first block ends the second will perform. With this logic, there won't exist inconsistencies that I can think of.

Of course one can say that this synchronization is inneficient. You can gain extra ms if you make your own semaphores... But I am 99% sure it is scalable enough for current avg mud players and current computer components

Ignoring some overheads, a threaded engine in the worst case will behave as non threaded. Plus the benefits of having threads controlling each system, debugging, and isolating errors.
Viriato is offline   Reply With Quote
Old 11-18-2012, 12:24 PM   #12
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: Event-based with threads instead of game loop

Ah! That's cool. I do use synchronized and static methods, but in this way you have actually created a passive bottleneck, instead of an ActionExecutor, which uses the fact that the JVM "enqueues" the subsequent calls to a synchronized function. It's still as similar to the idea of a game loop as mine but I must say, I love this implicit thing. I don't even think it's particularly difficult to maintain (not more than mine, since I have to take care that, apart from the actions which are executed sequentially, the data structures are not accessed/modified concurrently without synchronization, for example when a new player log in and it's inserted in a room which might be being iterated in a command).

@camlorn: nice stuff really! Scala has been put upper in my TOSTUDY list

Looking at my code again, however, I understood I'll not be changing it, not even with akka. The time is limited and I code comfortably with this approach, so unless I find some performance bottleneck that is implicit with my approach, I'll stick to it. For my next projects, though, I'll treasure the suggestions you've given me. Thank you.
koteko is offline   Reply With Quote
Reply


Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 07:35 AM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2022