views:

196

answers:

4

Hey,

I'm writing an AI-testing Framework for a competition. Participants submit a Bot class which matches a given Interface. Then all the bots play a turn-based game. On every turn, I want to do the following:

For every bot B:
    start a thread that runs at most N cycles and does B.getNextMove()
wait for all threads to complete
Make all moves (from each bot).

My difficulty comes in saying "at most N cycles". I can limit all the bots by time (say half a second per turn) but this means that some can get more processor cycles than others and doesn't permit a strict "your bot should be able to make its decision re: a turn in X time" requirement in the competition.

As stated, this is in Java. Any ideas? I've been looking at concurrency and locking but this doesn't feel like the right direction. Also, it's possible to not run the bots in Parralel and then use time for the restriction (given that the computer isn't running anything else at the time), but this would be undesirable as it would significantly slow down the speed at which we could have results from the games.

+1  A: 

Since you're controlling the bot execution and explicitly calling next yourself, why not just count the iterations? e.g.

public class Botcaller extends Thread 
{
  private Bot bot;
  int cycles_completed;
  public static final int MAX_ALLOWED_CYCLES=...;
  public void run()
  {
     while (cycles_completed <MAX_ALLOWED_CYCLES)
     {
       bot.move;
       cycles_completed++;
       yield()
     }
  }
}
Steve B.
That looks promising; how the "bot.move" line work? As far as the contestants are concerned, they just need to write a getNextMove() function, which takes less than N cycles to produce an answer. In this scenario, would they have to write "bot.move" instead, which now needs to break their algorithm into smaller bits?
AlexeyMK
I think that this responder either misunderstood what you meant by "cycles" or is suggesting that the bots be recoded in some way that is more granular... though that doesn't really keep them from doing more than they're supposed to in bot.move()
PSpeed
+4  A: 

I'd make an interface with the bot to have them do 1 iteration of their algorithm,and do a simple count.

If you need hard time/cpu limits there arn't that many(easy) ways to manage that in java.

You can't measure cpu cycles with java, but you can measure CPU time - which is a vast improvement over using just wall clock time.

To get the cpu time of the current thread you'd use (from the standard java.lang.management package)

ThreadMXBean tm = ManagementFactory.getThreadMXBean();
long cpuTime = tm.getCurrentThreadCpuTime();
nos
this looks like the most promising option. I assume (I'll check today) that theres a way to check non-current thread cpu time as well, since i want to have a management thread checking these things.
AlexeyMK
Yep, it works. You sir are a lifesaver.
AlexeyMK
Curious, what do you do with the CPU time once you have it?
PSpeed
Verify whether the thread has run for more than the GUARANTEED_CPU_TIME_ALLOTTED. This way we can say (to the contestants): your program should finish in under 500ms worth of Processor Cycles. We can guarantee at least that; you might get slightly more, but you can't depend on it.Over a large number of turns, the unfairness of the occasional additional time peters out. If you're interested: http://git.to/snake1 (warning: not polished)
AlexeyMK
A: 

I think it will be very difficult to control threads at this low a level from Java. I no of know way to stop a thread safely that is running.

Another option is to let each bot run in whatever time it wants. Have one thread per bot but poll the location in a master thread every second. If they haven't updated location in that "round" then they miss out and have to wait for the next one. Make sure that the world state that each bot sees is the one controlled by the master thread.

The nice thing about this approach is that it lets bots sacrifice rounds if they want to do something more complicated.

PSpeed
A: 

I think Robocode does something similar... you may want to look there.

Chris Nava