Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So let's say I have a server running on node.js, and there is an array of player objects...

At an interval, all of these player objects are looped and processed for events and changes that are based on time, such as fuel or food consumption and movement.

However players can also trigger things from the client that could modify player data as well.

Now what I'm trying to determine is if I am going to run into any problems with timing, such as if we are mid loop and somebody changes something and it throws some other calculation off balance.

Will I need to implement some kind of locking mechanism I can use as needed or is there a better way to hold this data in memory?

share|improve this question
up vote 1 down vote accepted

First and foremost you have to understand the JavaScript event model. JavaScript has an event list, whenever an event happens, that could be an incoming HTTP request, one of your intervals triggering, or a bunch of other stuff, that is event is put on a list. Events on that list are being handled one at a time, in the order in which they occurred, but not necessarily at the time when they occurred, since other prior events may need to be handled first.

This means that when you iterate over the array using a simple for loop, no other code is running, if a user takes an action that will change the array, the corresponding request will be handled only after you have finished.

The downside to this is of course that your users will experience a delay whenever you are doing an update. But this is not a problem unless your update takes a long time.

Beware that any code you put in a callback will be executed under a different event than the current code, so arbitrary other events may be handled in-between.

On a slightly related note, beware that the setTimeout and setInterval functions are not exact in their timing. In V8 an interval will "drift", taking breaks that are slightly longer than specified, or in some cases under heavy load a lot longer. If you want your updates to stick to a schedule you will have to use setTimeout, and in each iteration check how much off schedule it was executed and subtract that from the time set for the next update.

share|improve this answer
Wow great answer! I am using a setInterval now for processing the array of objects every few seconds. I am unsure at the moment if going off schedule will matter much, but if it will it's going to take a while in this project before I am likely to notice (figures right?). Now that I read up on the event model it looks like I don't have to worry as much as I previously thought about this. Thanks for the great insight! – ioSamurai Dec 22 '12 at 19:32

If multiple, independent agents can both use/modify the same data on the server, then it requires certain design principles to prevent problems.

  1. If the server environment is multi-threaded, then the access to the actual data on the server has to be protected with mutexes (or something similar like a multi-user database) so that changes to the data are atomic and no two threads or processes are ever trying to change the same piece of data at the same time and all data structures retain appropriate integrity no matter how many people are trying to change the same data at the same time.

  2. The client environment has to both know that any data it holds might be getting changed by another agent at any time and it has to be designed to handle that in its normal operation. There are a number of design strategies for handling that and which makes the most sense depends entirely upon the application.

  3. When the client wants to change data, it has to have a design strategy for how to handle the case where somebody else has already changed the data since you last saw it. The strategies can be as simple as "last writer wins" or much more involved requiring verification that the client knew the previous state of the data before changing it or even temporary locks while making a change.

share|improve this answer
-1 For completely ignoring the concept of the JavaScript event model. – aaaaaaaaaaaa Dec 22 '12 at 14:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.