Reinventing wheels?
Although the sample code implemented tick synchronization between worker thread and robot thread, the use of token may not be necessary, since Java already had similar mechanism.
worker = new Thread(() -> {
try {
while (true) {
Thread.sleep(1000);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
call worker.interrupt()
whenever you don't need it anymore, or just wait robocode to call that method for you.
It's more likely a sign of the state of Java (or the author's knowledge of it) at the time the page was drafted. It looks like the original is over 10 years old.
Besides Toad, do any bots actually make use of multithreading? I've always felt the community considered it to be a "dirty" tactic.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:Multithreading/Reinventing wheels?/reply (2).
I agree that computational tasks should not be allowed to run multithreaded in rumble or even in general robocode, or at least we should not allow threads to be run when other bots are running.
However as long as you do file I/O for data logging purposes, multithreading is essential as it’s not fair for your main threads to run blocking I/O only to get a lot skipped turns.
Anyway, a better solution is to provide this in robocode, so fairness is guaranteed.
I usually put the engine in debug mode if I am going to be logging a lot of data. Also, robocode does increase your processing time allowed if you do any file IO.
But debug mode disables security iirc? Then this mode is unsafe for running with arbitrary opponent. Also it seems that skipped turns has no special handling if you do IO. It just increases the max skipped turns allowed before you get disabled
Java already has nonblocking IO support, may be we should support this in robocode as well. Currently doing so requires disabling security.