Search the web
Sign In
New User? Sign Up
javajousters · Java Algorithms Challenges Group
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Want your group to be featured on the Yahoo! Groups website? Add a group photo to Flickr.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
Robot thread scheduling discussion.   Message List  
Reply | Forward Message #812 of 846 |
Hi All,

I believe that it would be possible to implement a scheduler that
works (from the point of view of the robots) in the same way as the
old CRobots did. AFAIK, from the postings in this mailing list,
CRobots used to multitask the robots by switching to another bot
whenever one entered an API function (like time()). It did this by
swapping the stacks.

This effect could be done in JRobots by having all the threads
sychronise on one object, and by notifying the next one to run.

This would have the following advantages and disadvantages (please
feel free to comment, and/or add to this list):


Advantages.

1. Each robot would run it's code, between API calls, as fast as possible.

2. It would be possible to monitor the CPU time used by each robot, as
we'd only have one running at once. We could then detect if any robot
is using too much time, and take some sort of action.

3. We could still schedule the timer thread to run, and so could still
adjust to CPU load, although this may be a little more tricky.

4. The scheduling algorithm is compatible with older JVMs.

5. We could choose to increment the simulation time in various ways.
A couple of possibilities would be (a) Make the API calls take some
set amount of time, or (b) Time how long the robot took to execute
it's code, and increment the simulation time proportionally (this
would automatically penalise the ones that used a lot a CPU).


Disadvantages.

1. The robots may make the assumption that other robots get CPU time
even when one robot is in a tight loop (e.g. in team mode, a bot could
wait in a tight loop until one of it's teammates updates a value).
This would definately no longer be possible. However, this assumption
by a robot is actually not a good idea, and IMO is quite unlikely.

2. Currently the simulation will probably adjust to use more CPUs in a
multi-cpu system. To do this with the new scheduling algorithm would
require that we detect how many CPUs there are, and that we then allow
more than 1 thread to run simultaneously. The current java API call
for this is only available from version 1.4+.


I'm a bit busy at the moment with work and TORCS :), but I may try out
a new scheduler at some point in the next weeks.


Cheers, Tim.





Wed Jun 20, 2007 10:51 am

timfoden
Offline Offline
Send Email Send Email

Forward
Message #812 of 846 |
Expand Messages Author Sort by Date

Hi All, I believe that it would be possible to implement a scheduler that works (from the point of view of the robots) in the same way as the old CRobots did....
Tim Foden
timfoden
Offline Send Email
Jun 20, 2007
10:51 am
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help