Performance Tweaking with Dynamic thread priority

General Discussions
#1

Ok,

I am (hopefully) going to get into the habit of tossing ideas out here on the forum and seeing what kind of response they generate.

The reason is that I am interested in Java Game development, and am inexperienced. I was going to back end the game I am modeling with java, and CORBA a connection to a C++ game client. But Java seems to have some 3d functionality now. if I get to the point where my skills surpass what java 3d apis can do for me, then I will turn back to C++.

Until then, threads:

What pros/cons are there to dynamically changing (via a command console, or an AI method) thread priorities during MMO server operations? I can think of several ways to do this, but is it worth it?

Currently I am working on developing the back end to a MMO game. It will start out a a generic engine allowing objects (be they players, NPCs, structures, or other game objects) to interact and move in a 3D environment. The environment will not be rendered at server side (of course), but the locations of all interactive objects will be. A thread will run each volume (location) and that thread will communicate with the game controller (main) via a container object.

(Interjection: !@#$ windows…cant use my vi nav keys…)

Here are my (ignorant ways) thoughts on how to do this:

  1. A config file, read in before the threads start, setting the thread start priorities for the game.
  2. A config file for each group of threads, that I can change, and every 1000 cycles or so (10,000, 100,000, etc) they check the file, and set their own priority according to what is in there.
  3. I send requests via the abovementioned container object to the thread to lift or lower priorities.
  4. I combine #2 and #3 above, by uing a file, and then sending a generic “check the priority file” message to the threads that I want prioritized.
  5. I set threshold limits to what is in the container objects, and if one gets backed up too much, the program automatically adjusts the priorities. I think this is the most dangerous method of all, but verry slick sounding.

SO, what d oyou think?

If all of this is stuff that I shouldn’t worry about, tell me. Be abusive if you want.

Thanks!
Jared

#2
  1. This should perhaps be moved to “online game development”?
  2. You don’t say why you want to modify thread priorities; you’re giving us the solution, but not the problem.
  3. thread priorities are pretty much irrelevant in java prior to 1.5 (IIRC there are some moves to give the thread priorities real meaning in 1.5?), except on particular platforms (e.g. Solaris, IIRC, does something reasonably useful with them)…
  4. …and even Sun advises you should not use thread priorities for anything except cosmetic stuff. They are not even guaranteed to have any noticeable effect, and are not guaranteed to not do bad things either, e.g. starve each other.
  5. What’s an MMO game? Do you mean 1k players, or 100k?

My guess is that you think that thread priorities might allow you to perform some kind of QoS or load balancing across locations.

#3

Yeah, kinda like load balancing.

I probably should move this discussion to the other forum listing.

Anyways, the reason I asked was I wanted to know, is it really necessary? If not, heck, I will flag it.

#4

It is rarely necessary to set thread priorities within a process that you control. Usually you have threads that need to do X amount of work and then block waiting for another thread. Priority adjustments (even if they did adjust real priorities in the native threads in a significant way) may not have any effect at all. One thread will get to the point where it blocks a bit sooner, that when the other thread catches up and un-blocks it… the end result is no noticeable difference.

My main point - don’t even think about this until you actually have a problem that you find is related to thread priorities.

#5

Indeed. I’d be more concerned about the crazy idea to use CORBA as the communications protocol.

Java 3D capabilities are now on a par with C++, and will remain that way. Design your client with this in mind - eg. there is no going back to that nasty dark world!

Cas :slight_smile:

#6

BTW.

We use thread priorities within the JDk so they definitely do something.

As the queuing algorithym is up to the latform then its true you cannot expect them to do other then the platform does. If the platform supports thread aging or some other fairness-gaurantee then you can count ont it, if it doesnt then you can’t.

As an example though, my current server (to be shown next week at GDC) uses low priority threads for queue processing and works well on both Win32 and Solaris.

#7

[quote]BTW.
We use thread priorities within the JDk so they definitely do something.
[/quote]
Sure; I’ve played with similar things myself on NT-x (although not for a couple of years, and I’d be interested to know how much mileage you get out of it today?). But Sun’s official advice has historically always said something like “do not write code that depends in any way upon thread priorities” - and IIRC that includes a warning not to use them for priority queues. I don’t think this has been changed for 1.4.x?

I’ve always assumed it was just ass-covering: the JVM spec doesn’t mandate much here, so Sun wants everyone to appreciate that and not come complaining if a particular JVM seems to screw up their scheduling :).